diagnostics
diagnostics copied to clipboard
dotnet
Update GCInfo deserializer once https://github.com/dotnet/runtime/pull/104336 merges
https://github.com/dotnet/runtime/pull/104336 changes the encoding of GC info in a breaking way. (arm/arm64 code offsets are encoded with fewer bits)
Once the runtime change goes in, the SOS copy will need to be updated correspondingly, to be able to dump from GcInfo v3
Re: https://github.com/dotnet/runtime/pull/104336#discussion_r1664993184
Note: this change was reverted on https://github.com/dotnet/runtime/pull/105234
@VSadov is the reverted runtime change going to eventually make it into .NET 9? Can I change this issue to .NET 10?
Pushed out to dev10. Sorry, I forgot to change this issue once it was clear it is not going to make it into 9.
The GCInfo change was merged into .NET 10 main. The commands to dump GCInfo are broken in SOS as of right now.
Now that the GC commands have been rewritten in C# and use CLRMD, this is problem a change in CLRMD.
This is about https://github.com/dotnet/diagnostics/blob/main/src/shared/vm/gcinfodecoder.cpp and related files. Was this decoder rewritten in C#? I am not aware of it.
Your right, the GCInfo is still in C++. @VSadov could you handle this?
I'd need some pointers where that code lives and how to test. As I understand there is a copy of gcinfodecoder somewhere in SOS/diagnostics and that is updated once in a while to pick changes. and that is what needs to be done.
Yes, it lives at https://github.com/dotnet/diagnostics/blob/main/src/shared/vm/gcinfodecoder.cpp
Note that this copy needs to be able to decode GCInfo for both current and past runtimes. The current copy in dotnet/runtime is not able to do that.
how to test.
Build the repo, load sos.dll from your local build into windbg, and inspect the output of !gcinfo command of a few methods on different versions of the runtime (e.g. .NET 8 and live .NET 10 should be enough).
Note that this copy needs to be able to decode GCInfo for both current and past runtimes.
Is that actually expected? GC info changes almost every release, but there seems to be nothing in SOS to handle versioning for different runtimes. Is it not expected that SOS.dll matches the version of the runtime?
Is it not expected that SOS.dll matches the version of the runtime?
We expect the same SOS.dll to work for all versions of the runtime.
It seems the GC info version is hardcoded in SOS the same way as in runtime - #define GCINFO_VERSION 3 which is in gcinfo.h
We may need a variant of ReadyToRunVersionToGcInfoVersion, but for JIT code.
How SOS code figures the runtime version in general?
We probably only need the major version here. (doubtful we will change GC info format in minor releases).
There are a set of helper functions like
bool IsRuntimeVersion(DWORD major)
bool IsRuntimeVersionAtLeast(DWORD major)
that will help.
Just checking: Is there any way to get the GCINFO version from the target and go from there?
The GC info itself does not record its version as it would be fairly wasteful when everything in the process is the same version.
R2R has some way of associating R2R version with GC Info version, but all the last times that we used this mechanism it was for small semantical differences in how info is interpreted. (i.e. safe points are interruptible or not). It would not typically affect actual parsing of the info.
Parsing of GC info is not shimmed/versioned in the runtime for performance reasons. If R2R assembly has a version that requires different kind of parsing, we will just ignore the R2R part of it and switch to JITing.
I think from the dumping/parsing point we can assume that pre-10.0 runtimes use v3 GC Info, and 10.0+ use v4
My current plan is to shim version-specific parts of GCInfo parsing in the SOS copy, but put the shimming under #ifdef so that we could backport that to runtime and continue keeping the files synchronized.