SOS not able to resolve symbols correctly when `COMPlus_TieredCompilation` is on
- Dominant language
- C++
- Stars
- 1.3k
- Forks
- 404
- Avg merge
- 2d 5h
- Merged PRs (30d)
- 35
Description
For curiosity and huge interest in JIT and assembly, I generally use the SharpLab tool to see the assembly code generated by the compiler. But recently I switched to [WinDbg](https://www.microsoft.com/en-us/p/windbg-preview/9pgjgd53tn86) to see generated ASM code by using this [workflow](https://twitter.com/ShreyasJejurkar/status/1496359786237263874).
But what could I notice was that Windbg (with loaded SOS extension) was not able to resolve the call instruction address to corresponding method names (symbols). I tried a bunch of various ways on the internet to fix this symbols issue. But didn't got any way to solve this. So I filled an issue at [StackOverflow ](https://stackoverflow.com/questions/70740497/windbg-cannot-resolve-net-core-libraries-symbols/70744914?noredirect=1#comment125901226_70744914) about the same. But didn't get an answer that solved my issue.
But yesterday while having a discussion with @kevingosse, he suggested me to turn off the tiered compilation and see if it works. And interestingly it does work. I started to get method symbols.
So I guess SOS is not updated to handle the TieredCompilation scenario. As `SOS.dll` comes with .NET SDK, I thought I should file this issue to let the team knows so that they fix this issue. Because these things are not documented anywhere, and this can literally wipe out newcomers or even advanced users' motivation to learn, explore or solve, debug issues respectively.
This is not a rant, but at least this thing should be documented somewhere if not fixed! Not sure if the runtime repo is correct to file this issue or the dotnet SDK's repo for the `SOS.dll`. Please let me know if I need to file this issue there!
Contributor guide
No contributing guide indexed for this repository
Assessment
This issue has not been assessed yet.