Updated gcdecoder from main #5369

VSadov · 2025-03-24T16:00:44Z

made the gcdecoder in sync with the 10.0 runtime.
made sure new SOS.dll can parse and do !gcinfo with both net10.0 and net8.0.

VSadov · 2025-03-24T22:12:34Z

Prior to this change doing !gcinfo for System.Threading.ManualResetEventSlim.Wait on net8.0 runtime produces:

0:000> !gcinfo 00007fff2906893e
entry point 00007FFF29068780
preJIT generated code
GC info 00007FFF28D8C778
Pointer table:
Prolog size: 0
GS cookie: <none>
PSPSym: initial.sp+30
Generics inst context: <none>
PSP slot: caller.sp+30
GenericInst slot: <none>
Varargs: 0
Frame pointer: rbp
Wants Report Only Leaf: 1
Size of parameter area: 30
Return Kind: Scalar                                         <-- correctly reports return kind
Code size: 460
Untracked: +rbp+20 +rbp-48
00000035 interruptible
00000035 +rbp+10 +rcx
0000004d +rax
00000057 -rax
00000069 -rcx
000000a4 +rcx
000000be -rcx
000000c2 +rcx
000000c8 -rcx
000000ce +rax(interior)
000000d5 +r8
. . .   and so on. Long list of liveness changes.

Same with net10.0

:000> !gcinfo 00007ffeb9c01302
entry point 00007FFEB9C01130
preJIT generated code
GC info 00007FFEB989684C
Pointer table:
Prolog size: 0
GS cookie: <none>
PSPSym: initial.sp+200
Generics inst context: <none>
PSP slot: caller.sp+200
GenericInst slot: <none>
Varargs: 0
Frame pointer: r13
Wants Report Only Leaf: 1
Size of parameter area: 6160
Return Kind: {ByRef, Object}         <-   10.0 no longer includes Return Kind in GC Info. This is bogus. And most other info too, since the return kind was right after header flags.
Code size: 93
c0000005 Exception in C:\Users\<userName>\.dotnet\sos\sos.dll.gcinfo debugger extension.
      PC: 00007ffe`b9403065  VA: 0000028d`2c14de28  R/W: 0  Parameter: 00000000`00000000

After this PR with net10.0

0:000> !gcinfo 00007ffeb9d51302
entry point 00007FFEB9D51130
preJIT generated code
GC info 00007FFEB99E684C
Pointer table:
Prolog size: 0
GS cookie: <none>
PSPSym: initial.sp+30
Generics inst context: <none>
PSP slot: caller.sp+30
GenericInst slot: <none>
Varargs: 0
Frame pointer: rbp
Wants Report Only Leaf: 1
Size of parameter area: 30
Code size: 436
Untracked: +rbp+20 +rbp-48
00000034 interruptible
00000034 +rbp+10 +rcx
0000004c +r8
00000057 -r8
0000005c -rbp+10 -rcx
00000066 +r8
00000073 -r8
00000074 +rbp+10 +rcx
0000007a -rcx
000000b1 +rcx
000000c7 -rcx

noahfalk · 2025-03-24T23:37:14Z

@mikem8361 to take a closer look from the SOS side

@VSadov - SOS needs to work with both new and old versions of .NET and it wasn't clear to me if the current PR handles that? I noticed over on #4795 that discussion around that was already happening so great 👍

VSadov · 2025-03-25T06:38:59Z

and now the new SPS.dll can also decode gcinfo in a net8.0 process:

The same System.Threading.ManualResetEventSlim.Wait on net8.0 runtime produces:

0:000> !gcinfo 00007ffeb445893e 
entry point 00007FFEB4458780
preJIT generated code
GC info 00007FFEB417C778
Pointer table:
Prolog size: 0
GS cookie: <none>
PSPSym: initial.sp+30
Generics inst context: <none>
PSP slot: caller.sp+30
GenericInst slot: <none>
Varargs: 0
Frame pointer: rbp
Wants Report Only Leaf: 1
Size of parameter area: 30
Return Kind: Scalar                            <-- reports Return Kind for old format that tracks it.
Code size: 460
Untracked: +rbp+20 +rbp-48
00000035 interruptible
00000035 +rbp+10 +rcx
0000004d +rax
00000057 -rax
00000069 -rcx
000000a4 +rcx
000000be -rcx
000000c2 +rcx
000000c8 -rcx
000000ce +rax(interior)
. . .

VSadov · 2025-03-25T16:05:54Z

Looks like an unrelated failure: System.Net.Sockets.SocketException : Connection refused

VSadov · 2025-03-25T16:21:03Z

I think the change has all that was planned. Please take a look.
CC: @jkotas

src/shared/inc/gcinfo.h

src/shared/inc/gcinfodecoder.h

VSadov · 2025-03-25T16:31:15Z

src/shared/vm/gcinfodecoder.cpp

-bool GcInfoDecoder::IsInterruptibleSafePoint()
-{
-    return IsSafePoint() && AreSafePointsInterruptible();
-}


These were helpers for where we can suspend and where we cannot (it all got simpler now).
This does not need to be shimmed as this has no effect on gcinfo dumper.

src/shared/inc/gcinfodecoder.h

jkotas · 2025-03-25T16:28:53Z

src/shared/inc/gcinfotypes.h

 #define CODE_OFFSETS_NEED_NORMALIZATION 1
-#define NORMALIZE_CODE_OFFSET(x) (x)   // Instructions are 2/4 bytes long in Thumb/ARM states,
-#define DENORMALIZE_CODE_OFFSET(x) (x) // but the safe-point offsets are encoded with a -1 adjustment.
+#define NORMALIZE_CODE_OFFSET(x) ((x)>>1)   // Instructions are 2/4 bytes long in Thumb/ARM states,


These macros were changed to methods in dotnet/runtime main. Do you plan to pick up that update separately?

Must have happened recently. I used fairly recent baseline, but perhaps not the latest.

I am thinking to open a parallel PR in runtime with same files content, to make sure we do not need to shuffle changes back and forth.

I am thinking to open a parallel PR in runtime with same files content,

Yes, I think that's a good idea.

Opened dotnet/runtime#113888

Also re-tested in WinDbg if !gcinfo still works after updating from runtime/main, with both 8.0 and 10.0

VSadov · 2025-03-27T02:09:52Z

This code can tell you if it is .NET Framework:

if (g_pRuntime->GetRuntimeConfiguration() == IRuntime::WindowsDesktop)

That does not want to work at the level of GC Info Decoder. I noticed that all the calls to this in at the strike.cpp level.
I think we can check for .NET FX for the purpose of GC Info version at strike.cpp level as well.

We do not need .NET FX detection in the Core repo anyways. As long as decoder specialcases V1 and V1 is set somehow for .Net FX, this should work as before.

VSadov · 2025-03-27T02:17:28Z

I am not sure how to test .NET FX support in SOS though.

The same thing as I try for Core (i.e. load SOS.dll in WinDbg and examine some methods) does not work for me.
I am getting errors when trying to load.

0:000> .load E:\diagnostics\diagnostics\artifacts\bin\Windows_NT.x64.Release\sos.dll
The call to LoadLibrary(E:\diagnostics\diagnostics\artifacts\bin\Windows_NT.x64.Release\sos.dll) failed, Win32 error 0n193
    "%1 is not a valid Win32 application."
Please check your debugger configuration and/or network access.
Extension DLL search Path:
    C:\Program Files\WindowsApps\Microsoft.WinDbg_1.2502.25002.0_x64__8wekyb3d8bbwe\x86\WINXP;C:\Program Files\WindowsApps\Microsoft.WinDbg_1.2502.25002.0_x64__8wekyb3d8bbwe\x86\winext;C:\Program Files\WindowsApps\Microsoft.WinDbg_1.2502.25002.0_x64__8wekyb3d8bbwe\x86\winext\arcade;C:\Program Files\WindowsApps\Microsoft.WinDbg_1.2502.25002.0_x64__8wekyb3d8bbwe\x86\pri;C:\Program 

. . . lots of directories in search path . . .

You may also consider deploying your extension to the UserExtensions extension gallery repository
located at %LOCALAPPDATA%\dbg\UserExtensions folder. It would require an extension manifest.
Error: Failed to load extension E:\diagnostics\diagnostics\artifacts\bin\Windows_NT.x64.Release\sos.dll

Same error happens with the SOS.dll from C:\Users\<user>\.dotnet\sos

I do not think this is related to the change. Maybe I am using this incorrectly... (I am not a frequent user of SOS)

VSadov · 2025-03-27T06:01:49Z

Figured why I could not test. .Net FX defaults to 32bit and thus I had a bitness mismatch.

Also I found that the change that supposedly "fixes" !gcinfo on .Net FX actually breaks it.

The reason is that the switch from GC Info v1 --> GC info v2 seems like happened in .Net FX times.

The NDP sources that I have (which are by themselves very old) have
(NDP\clr\src\inc\gcinfo.h)

#define GCINFO_VERSION 2

. . . 

    static UINT32 ReadyToRunVersionToGcInfoVersion(UINT32 readyToRunMajorVersion)
    {
        // GcInfo version is 1 up to ReadyTorun version 1.x
        // GcInfo version is current from  ReadyToRun version 2.0
        return (readyToRunMajorVersion == 1) ? 1 : GCINFO_VERSION;
    }

Since R2R is a CoreClr thing, does this mean that GCInfo v1 is effectively dead - either on .Net FX or on CoreCLR ?

jkotas · 2025-03-27T06:19:04Z

GCInfo v1 is effectively dead - either on .Net FX or on CoreCLR ?

Sounds like it.

VSadov · 2025-03-27T06:23:06Z

I will revert to the commit that does not handle GC_INFO_FLAGS_BIT_SIZE_VERSION_1

Co-authored-by: Jan Kotas <jkotas@microsoft.com>

src/shared/inc/gcinfo.h

VSadov · 2025-03-27T19:18:46Z

@mikem8361 The runtime part of this change is ready to go. Please take one more look from diagnostics side.

VSadov · 2025-04-04T02:01:12Z

Thanks!!

VSadov · 2025-04-04T02:02:23Z

Looks like I do not have permissions to merge in this repo, so someone else should merge.

VSadov marked this pull request as ready for review March 24, 2025 22:13

VSadov requested a review from a team as a code owner March 24, 2025 22:13

VSadov commented Mar 25, 2025

View reviewed changes

src/shared/inc/gcinfo.h Show resolved Hide resolved

VSadov commented Mar 25, 2025

View reviewed changes

src/shared/inc/gcinfodecoder.h Show resolved Hide resolved

VSadov commented Mar 25, 2025

View reviewed changes

jkotas reviewed Mar 25, 2025

View reviewed changes

VSadov mentioned this pull request Mar 25, 2025

Parallel change to the diagnostic update for GC Info decoder. dotnet/runtime#113888

Merged

VSadov force-pushed the gcDec branch from 9ba2a67 to f65d44f Compare March 27, 2025 02:05

VSadov force-pushed the gcDec branch from f65d44f to 9ba2a67 Compare March 27, 2025 06:19

VSadov and others added 11 commits March 26, 2025 23:26

updated gcdecoder from main

ed31baf

DENORMALIZE_CODE_OFFSET on RISC

34f485d

keep formatting

11a3c47

shim code offset normalization

af48306

shim ReturnKind

765c127

shim safepoint decoding

22a605e

Apply suggestions from code review

20ff2d6

Co-authored-by: Jan Kotas <jkotas@microsoft.com>

couple more changes from PR review

3a44380

update from most recent runtime main

5e869b3

decoder does not need to worry about parsing GCInfo V1

ab4fde3

fix for unix

79c5192

VSadov force-pushed the gcDec branch from 9ba2a67 to 79c5192 Compare March 27, 2025 06:26

VSadov commented Mar 27, 2025

View reviewed changes

src/shared/inc/gcinfo.h Show resolved Hide resolved

clarified a comment

cc5fc46

mikem8361 approved these changes Apr 4, 2025

View reviewed changes

mikem8361 merged commit 07a1f3e into dotnet:main Apr 4, 2025
21 checks passed

github-actions bot locked and limited conversation to collaborators May 5, 2025

Updated gcdecoder from main #5369

Updated gcdecoder from main #5369

Uh oh!

Conversation

VSadov commented Mar 24, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

VSadov commented Mar 24, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

noahfalk commented Mar 24, 2025

Uh oh!

VSadov commented Mar 25, 2025

Uh oh!

VSadov commented Mar 25, 2025

Uh oh!

VSadov commented Mar 25, 2025

Uh oh!

Uh oh!

Uh oh!

VSadov Mar 25, 2025

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

jkotas Mar 25, 2025

Choose a reason for hiding this comment

Uh oh!

VSadov Mar 25, 2025

Choose a reason for hiding this comment

Uh oh!

jkotas Mar 25, 2025

Choose a reason for hiding this comment

Uh oh!

VSadov Mar 25, 2025

Choose a reason for hiding this comment

Uh oh!

VSadov Mar 25, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

VSadov commented Mar 27, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

VSadov commented Mar 27, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

VSadov commented Mar 27, 2025

Uh oh!

jkotas commented Mar 27, 2025

Uh oh!

VSadov commented Mar 27, 2025

Uh oh!

Uh oh!

VSadov commented Mar 27, 2025

Uh oh!

VSadov commented Apr 4, 2025

Uh oh!

VSadov commented Apr 4, 2025

Uh oh!

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

VSadov commented Mar 24, 2025 •

edited

Loading

VSadov commented Mar 24, 2025 •

edited

Loading

VSadov Mar 25, 2025 •

edited

Loading

VSadov commented Mar 27, 2025 •

edited

Loading

VSadov commented Mar 27, 2025 •

edited

Loading