Interpreter GC info stage 2: Generate empty GC info and add baseline implementation of EnumGcRefs

[kg]

• Modify GcInfoEncoder and its sibling files so that they can be successfully linked into the interpreter module; added new gcinfohelpers.h file with support code and macros
  • There are a couple load-bearing asserts inside the encoder that need to be evaluated for safemath to not explode in debug builds of crossgen2.
• Add new InterpreterGcInfoEncoder and InterpreterGcInfoDecoder
• Link gcinfo into the interpreter so the encoder and decoder are available
• At the end of interpreter method compilation, use InterpreterGcInfoEncoder to generate gc info for the method. EnumGcRefs will fail if we don't do this. We need to specifically do this at the end after the code header has been allocated, we can't do it earlier.
• Add placeholder implementation of EnumGcRefs for the interpreter, modeled on the existing one for the JIT.
• Add placeholder interp opcode that triggers a GC, so that we can easily test gcinfo and stackwalking in various interpreter scenarios.

[dotnet-policy-service]

Tagging subscribers to this area: @mangod9
See info in area-owners.md if you want to be subscribed.

[Copilot]

Pull Request Overview

This PR introduces baseline implementations for GC info generation and decoding in the interpreter, laying the groundwork for EnumGcRefs and improved GC info encoder/decoder functionality. Key changes include disabling some logging/assertions temporarily in GC info encoding, adding new InterpreterGcInfoEncoder/Decoder, and triggering a GC in the interpreter tests for stackwalking validation.

Files not reviewed (16)

• src/coreclr/gcinfo/arraylist.cpp: Language not supported
• src/coreclr/gcinfo/gcinfodumper.cpp: Language not supported
• src/coreclr/gcinfo/gcinfohelpers.h: Language not supported
• src/coreclr/inc/bitposition.h: Language not supported
• src/coreclr/inc/gcinfodecoder.h: Language not supported
• src/coreclr/inc/gcinfoencoder.h: Language not supported
• src/coreclr/inc/gcinfotypes.h: Language not supported
• src/coreclr/interpreter/CMakeLists.txt: Language not supported
• src/coreclr/interpreter/compiler.cpp: Language not supported
• src/coreclr/interpreter/compiler.h: Language not supported
• src/coreclr/interpreter/eeinterp.cpp: Language not supported
• src/coreclr/interpreter/intops.def: Language not supported
• src/coreclr/vm/codeman.cpp: Language not supported
• src/coreclr/vm/eetwain.cpp: Language not supported
• src/coreclr/vm/gcinfodecoder.cpp: Language not supported
• src/coreclr/vm/interpexec.cpp: Language not supported

[kg]

There are some Interpreter-FIXMEs/Interpreter-TODOs left in here that I still haven't figured out what to do with, so thoughts on those are appreciated. In particular I don't love how I ended up solving various assertion-related problems here.

I've manually verified that when the interpreter test performs a GC collection, the stackwalker visits each interpreted frame and uses the gc info decoder to see that there are no gc refs on the stack.

cc @jkotas @janvorli @BrzVlad @lateralusX

[kg]

• Rebased.
• Updated to fix an assertion in GcInfoEncoder (I wasn't setting the codelength, and passing a length of zero to a function it calls is invalid).
• Attempting to fix the interp_nomem so it is treated as noreturn by clang.

[kg]

The checked lanes that get through build are failing on the interp tests, I'm not really sure I understand the error though:

Xunit.Sdk.TrueException: 
Assert failure(PID 3568 [0x00000df0], Thread: 3200 [0x0c80]): Consistency check failed: 
FAILED: GetControlPC(m_crawl.pRD) == m_crawl.pFrame->GetReturnAddress()

CORECLR! CHECK::Trigger + 0x1C4 (0x00007ffe`5c625f5c)
CORECLR! StackFrameIterator::NextRaw + 0x188 (0x00007ffe`5c369110)
CORECLR! Thread::StackWalkFramesEx + 0x284 (0x00007ffe`5c36a78c)
CORECLR! Thread::StackWalkFrames + 0x12C (0x00007ffe`5c36a474)
CORECLR! ScanStackRoots + 0x288 (0x00007ffe`5c40ed38)
CORECLR! GCToEEInterface::GcScanRoots + 0x164 (0x00007ffe`5c40da64)
CORECLR! WKS::gc_heap::mark_phase + 0x334 (0x00007ffe`5c5c0c2c)
CORECLR! WKS::gc_heap::gc1 + 0x23C (0x00007ffe`5c5b702c)
CORECLR! WKS::gc_heap::garbage_collect + 0x684 (0x00007ffe`5c5b6db4)
CORECLR! WKS::GCHeap::GarbageCollectGeneration + 0x49C (0x00007ffe`5c59d44c)
    File: D:\a\_work\1\s\src\coreclr\vm\stackwalk.cpp:2338
    Image: C:\h\w\A350090D\p\corerun.exe


Return code:      1
Raw output file:      C:\h\w\A350090D\w\A0CD0881\uploads\interpreter\InterpreterTester\output.txt
Raw output:
BEGIN EXECUTION
 "C:\h\w\A350090D\p\corerun.exe" -p "System.Reflection.Metadata.MetadataUpdater.IsSupported=false" -p "System.Runtime.Serialization.EnableUnsafeBinaryFormatterSerialization=true"  InterpreterTester.dll 
Interpreted App returned -1073740286
System.Exception: Interpreted App failed execution
   at InterpreterTester.RunTests()
   at __GeneratedMainWrapper.Main()
Expected: 100
Actual: 101
END EXECUTION - FAILED
FAILED

Any ideas? It doesn't fail locally for me in a debug build, I'm assuming something is different about Checked

[janvorli]

This looks like the InterpreterFrame was skipped for some reason. The check that asserts is not valid for the InterpreterFrame, but I am not sure why it is declared as skipped.
You mentioned that you are not hitting it locally, are you testing it on Unix? These checks are used on Windows only, because they use the infrastructure that we use for contract checking that we never enabled for Unix.

[kg]

This looks like the InterpreterFrame was skipped for some reason. The check that asserts is not valid for the InterpreterFrame, but I am not sure why it is declared as skipped. You mentioned that you are not hitting it locally, are you testing it on Unix? These checks are used on Windows only, because they use the infrastructure that we use for contract checking that we never enabled for Unix.

I test on win11 with debug builds. I assumed debug builds would have all the possible checks enabled, do I need to test in checked builds instead? It works both from the command line and in the debugger.

[janvorli]

I assumed debug builds would have all the possible checks enabled

Yes, that's correct for Windows

[kg]

Is there an intended way to disable our weird "return" instrumentation? I'm running into it again, this time it breaks <new> so I don't have access to std::bad_alloc. I already had to introduce a workaround for the gcinfo stuff, so having to disable it again here feels like a pattern that might need a better solution:

[ 26%] Building CXX object nativeaot/Runtime/Full/CMakeFiles/Runtime.WorkstationGC.dir/__/MethodTable.cpp.o
  In file included from /usr/local/include/c++/14.2.0/algorithm:60,
                   from /__w/1/s/src/coreclr/interpreter/interpreter.h:18,
                   from /__w/1/s/src/coreclr/interpreter/compiler.cpp:4:
  /usr/local/include/c++/14.2.0/bits/stl_algobase.h: In function ‘constexpr int std::__size_to_integer(int)’:
  /usr/local/include/c++/14.2.0/bits/stl_algobase.h:1034:44: error: body of ‘constexpr’ function ‘constexpr int std::__size_to_integer(int)’ not a return-statement
   1034 |   __size_to_integer(int __n) { return __n; }
        |                                            ^
  /usr/local/include/c++/14.2.0/bits/stl_algobase.h: In function ‘constexpr unsigned int std::__size_to_integer(unsigned int)’:
  /usr/local/include/c++/14.2.0/bits/stl_algobase.h:1036:49: error: body of ‘constexpr’ function ‘constexpr unsigned int std::__size_to_integer(unsigned int)’ not a return-statement
   1036 |   __size_to_integer(unsigned __n) { return __n; }
        |                                                 ^

MSVC doesn't seem to mind, but it consistently breaks the linux build.

[kg]

I assumed debug builds would have all the possible checks enabled

Yes, that's correct for Windows

I can verify that the interpreter tests fail locally in Checked configuration and not Debug. So it's something specific to the Debug configuration that makes it work, and isn't happening in Checked builds. I'll poke around but I'm not really sure what's up there.

EDIT: Even more interesting, it's sufficient to run a checked version of the test using a debug corerun.

[kg]

It looks like for some reason we're building the interpreter module for x86, even though it won't work there, and it's failing to link as a result:

[1902/1922] Linking CXX shared library interpreter\clrinterpreter.dll
  FAILED: interpreter/clrinterpreter.dll interpreter/clrinterpreter.lib 
  C:\Windows\system32\cmd.exe /C "cd . && "C:\Program Files\Microsoft Visual Studio\2022\Enterprise\Common7\IDE\CommonExtensions\Microsoft\CMake\CMake\bin\cmake.exe" -E vs_link_dll --intdir=interpreter\CMakeFiles\clrinterpreter.dir --rc=C:\PROGRA~2\WI3CF2~1\10\bin\100261~1.0\x64\rc.exe --mt=C:\PROGRA~2\WI3CF2~1\10\bin\100261~1.0\x64\mt.exe --manifests  -- C:\PROGRA~1\MICROS~1\2022\ENTERP~1\VC\Tools\MSVC\1442~1.344\bin\Hostx64\x86\link.exe /nologo gcinfo\CMakeFiles\gcinfo.dir\arraylist.cpp.obj gcinfo\CMakeFiles\gcinfo.dir\gcinfoencoder.cpp.obj gcinfo\CMakeFiles\gcinfo.dir\simplerhash.cpp.obj gcinfo\CMakeFiles\gcinfo.dir\__\gcdump\gcdump.cpp.obj gcinfo\CMakeFiles\gcinfo.dir\__\gcdump\i386\gcdumpx86.cpp.obj interpreter\CMakeFiles\clrinterpreter.dir\compiler.cpp.obj interpreter\CMakeFiles\clrinterpreter.dir\compileropt.cpp.obj interpreter\CMakeFiles\clrinterpreter.dir\intops.cpp.obj interpreter\CMakeFiles\clrinterpreter.dir\eeinterp.cpp.obj  /out:interpreter\clrinterpreter.dll /implib:interpreter\clrinterpreter.lib /pdb:interpreter\clrinterpreter.pdb /dll /version:0.0 /machine:X86 /DEPENDENTLOADFLAG:0x800 /MANIFEST:NO /LARGEADDRESSAWARE /PDBCOMPRESS /DEBUG /DEBUGTYPE:CV,FIXUP /IGNORE:4197,4013,4254,4070,4221 /SUBSYSTEM:WINDOWS,6.01 /sourcelink:D:/a/_work/1/s/artifacts/obj/native.sourcelink.json  /OPT:REF /OPT:ICF /INCREMENTAL:NO /NODEFAULTLIB:libucrt.lib /DEFAULTLIB:ucrt.lib  /guard:cf /INCREMENTAL:NO /LTCG /DEF:interpreter\clrinterpreter.def  libcmt.lib  libvcruntime.lib && cd ."
  LINK: command "C:\PROGRA~1\MICROS~1\2022\ENTERP~1\VC\Tools\MSVC\1442~1.344\bin\Hostx64\x86\link.exe /nologo gcinfo\CMakeFiles\gcinfo.dir\arraylist.cpp.obj gcinfo\CMakeFiles\gcinfo.dir\gcinfoencoder.cpp.obj gcinfo\CMakeFiles\gcinfo.dir\simplerhash.cpp.obj gcinfo\CMakeFiles\gcinfo.dir\__\gcdump\gcdump.cpp.obj gcinfo\CMakeFiles\gcinfo.dir\__\gcdump\i386\gcdumpx86.cpp.obj interpreter\CMakeFiles\clrinterpreter.dir\compiler.cpp.obj interpreter\CMakeFiles\clrinterpreter.dir\compileropt.cpp.obj interpreter\CMakeFiles\clrinterpreter.dir\intops.cpp.obj interpreter\CMakeFiles\clrinterpreter.dir\eeinterp.cpp.obj /out:interpreter\clrinterpreter.dll /implib:interpreter\clrinterpreter.lib /pdb:interpreter\clrinterpreter.pdb /dll /version:0.0 /machine:X86 /DEPENDENTLOADFLAG:0x800 /MANIFEST:NO /LARGEADDRESSAWARE /PDBCOMPRESS /DEBUG /DEBUGTYPE:CV,FIXUP /IGNORE:4197,4013,4254,4070,4221 /SUBSYSTEM:WINDOWS,6.01 /sourcelink:D:/a/_work/1/s/artifacts/obj/native.sourcelink.json /OPT:REF /OPT:ICF /INCREMENTAL:NO /NODEFAULTLIB:libucrt.lib /DEFAULTLIB:ucrt.lib /guard:cf /INCREMENTAL:NO /LTCG /DEF:interpreter\clrinterpreter.def libcmt.lib libvcruntime.lib" failed (exit code 1120) with the following output:
     Creating library interpreter\clrinterpreter.lib and object interpreter\clrinterpreter.exp
  gcdumpx86.cpp.obj : error LNK2001: unresolved external symbol "unsigned int __fastcall decodeSigned(unsigned char const *,int *)" (?decodeSigned@@YIIPBEPAH@Z)
  gcdumpx86.cpp.obj : error LNK2001: unresolved external symbol "void __fastcall decodeCallPattern(int,unsigned int *,unsigned int *,unsigned int *,unsigned int *)" (?decodeCallPattern@@YIXHPAI000@Z)
  gcdumpx86.cpp.obj : error LNK2001: unresolved external symbol "unsigned int __fastcall decodeUDelta(unsigned char const *,unsigned int *,unsigned int)" (?decodeUDelta@@YIIPBEPAII@Z)
  gcdumpx86.cpp.obj : error LNK2001: unresolved external symbol "unsigned int __fastcall decodeUnsigned(unsigned char const *,unsigned int *)" (?decodeUnsigned@@YIIPBEPAI@Z)
  gcdumpx86.cpp.obj : error LNK2001: unresolved external symbol "unsigned char const * __fastcall decodeHeader(unsigned char const *,unsigned int,struct InfoHdr *)" (?decodeHeader@@YIPBEPBEIPAUInfoHdr@@@Z)
  
  gcdumpx86.cpp.obj : error LNK2001: unresolved external symbol "unsigned int const * const callCommonDelta" (?callCommonDelta@@3QBIB)
  
  interpreter\clrinterpreter.dll : fatal error LNK1120: 6 unresolved externals

My guess is this is because I feature flag guarded the interpreter gc info decoder/encoder. Should I not feature guard them?

[jkotas]

Is there an intended way to disable our weird "return" instrumentation?

@jkoritzinsky has been looking into deleting it.

[jkotas]

My guess is this is because I feature flag guarded the interpreter gc info decoder/encoder. Should I not feature guard them?

My guess is that the problem is caused by gcdumpx86 being pulled into clrinterpreter. Nothing in clrinterpreter should need the dumper of the special x86 gc info.

I would not bother with x86. I do not think we will spend time on making interpreter work on x86.

[kg]

The CLR_Tools_Tests failure looks like an existing problem and not me:

xUnit.net Console Runner v2.9.2+82543a6df6 (64-bit .NET 10.0.0-preview.3.25162.19)
�[37m  Discovering: ILCompiler.Trimming.Tests
�[m�[37m  Discovered:  ILCompiler.Trimming.Tests
�[m�[37m  Starting:    ILCompiler.Trimming.Tests
�[m�[31;1m    Mono.Linker.Tests.TestCases.All.DataFlow(t: "DynamicObjects") [FAIL]
�[m�[37m      Unexpected warning found: ILC: AOT analysis warning IL3050: Mono.Linker.Tests.Cases.DataFlow.DynamicObjects.DynamicInRequiresUnreferencedCodeClass.ClassWithRequires.MethodWithDynamicArg(Object): Using member 'System.Runtime.CompilerServices.CallSite`1<Action`2<CallSite,Object>>.Create(CallSiteBinder)' which has 'RequiresDynamicCodeAttribute' can break functionality when AOT compiling. Creating arrays at runtime requires dynamic code generation.
�[m�[30;1m      Stack Trace:
�[m�[37m        /_/src/coreclr/tools/aot/ILCompiler.Trimming.Tests/TestCasesRunner/ResultChecker.cs(405,0): at Mono.Linker.Tests.TestCasesRunner.ResultChecker.VerifyLoggedMessages(AssemblyDefinition original, TrimmingTestLogger logger, Boolean checkRemainingErrors)
�[m�[37m        /_/src/coreclr/tools/aot/ILCompiler.Trimming.Tests/TestCasesRunner/ResultChecker.cs(157,0): at Mono.Linker.Tests.TestCasesRunner.ResultChecker.AdditionalChecking(TrimmedTestCaseResult linkResult, AssemblyDefinition original)
�[m�[37m        /_/src/coreclr/tools/aot/ILCompiler.Trimming.Tests/TestCasesRunner/ResultChecker.cs(70,0): at Mono.Linker.Tests.TestCasesRunner.ResultChecker.Check(TrimmedTestCaseResult testResult)
�[m�[37m        /_/src/coreclr/tools/aot/ILCompiler.Trimming.Tests/TestCases/TestSuites.cs(154,0): at Mono.Linker.Tests.TestCases.All.Run(String testName)
�[m�[37m        /_/src/coreclr/tools/aot/ILCompiler.Trimming.Tests/TestCases/TestSuites.cs(16,0): at Mono.Linker.Tests.TestCases.All.DataFlow(String t)
�[m�[37m           at InvokeStub_All.DataFlow(Object, Span`1)
�[m�[37m           at System.Reflection.MethodBaseInvoker.InvokeWithOneArg(Object obj, BindingFlags invokeAttr, Binder binder, Object[] parameters, CultureInfo culture)
�[m�[37m  Finished:    ILCompiler.Trimming.Tests
�[m�[37m=== TEST EXECUTION SUMMARY ===
�[m�[37m   ILCompiler.Trimming.Tests  Total: 601, Errors: 0, Failed: 1, Skipped: 0, Time: 48.497s
�[m�[m=== COMMAND LINE ===
"/__w/1/s/.dotnet/dotnet" exec --depsfile "/__w/1/s/artifacts/bin/ILCompiler.Trimming.Tests/x64/Checked/ILCompiler.Trimming.Tests.deps.json" --runtimeconfig "/__w/1/s/artifacts/bin/ILCompiler.Trimming.Tests/x64/Checked/ILCompiler.Trimming.Tests.runtimeconfig.json"  "/__w/1/s/.packages/xunit.runner.console/2.9.2/tools/netcoreapp2.0/xunit.console.dll" "/__w/1/s/artifacts/bin/ILCompiler.Trimming.Tests/x64/Checked/ILCompiler.Trimming.Tests.dll" -noautoreporters -xml "/__w/1/s/artifacts/TestResults/Checked/ILCompiler.Trimming.Tests_net10.0_x64.xml" -html "/__w/1/s/artifacts/TestResults/Checked/ILCompiler.Trimming.Tests_net10.0_x64.html"  > "/__w/1/s/artifacts/log/Checked/ILCompiler.Trimming.Tests_net10.0_x64.log" 2>&1

[janvorli]

The CLR_Tools_Tests failure looks like an existing problem and not me:

Yes, it has been failing on every PR since yesterday. I have created an issue for it, but the CI build analysis somehow cannot see it.

[kg]

Any idea why I'm getting errors on ARM from my use of __cdecl in the definition of assertAbort?

I don't know why it complains there, but not in JIT where it is also used unconditionally. However, if you prevent defining our _ASSERTE in the DAC as I've mentioned above, this issue may be gone, because it complains in DAC build.

Thanks, I think I see what you mean by this and am making the relevant changes. Sorry for missing the nuance earlier when you described how to fix this :)

[kg]

I noticed I forgot to initialize gInterpJitInfoTls; I'll push a commit that fixes that once I see what happens with this latest CI run.

[kg]

Looks like someone modified gcinfoencoder.cpp so I have a complex manual merge ahead of me.

[janvorli]

Looks like someone modified gcinfoencoder.cpp so I have a complex manual merge ahead of me.

It came from https://github.com/dotnet/runtime/pull/114630/files#diff-9bff0b750b561ba1817a4235cf8a1d4d55118ab7bd026d3c65745aebb1c03eb9

There weren't that many changes, mostly deletes. So I guess taking your changes and applying the changes from that commit manually might be the least painful way.

[kg]

Looks like someone modified gcinfoencoder.cpp so I have a complex manual merge ahead of me.

It came from https://github.com/dotnet/runtime/pull/114630/files#diff-9bff0b750b561ba1817a4235cf8a1d4d55118ab7bd026d3c65745aebb1c03eb9

There weren't that many changes, mostly deletes. So I guess taking your changes and applying the changes from that commit manually might be the least painful way.

Yeah I think that's the right approach in this case, I just need to be careful not to lose any of the changes.

[kg]

Does anyone have objections to landing this so part 3 can leave draft and get reviewed? Happy to make more changes but I think I've addressed everything.

[janvorli]

LGTM, thank you!

[kg]

/ba-g known test issue
#115006