[cDAC] Support x86 stackwalking

[max-charlamb]

Changes

IExecutionManager

• GetFuncletStartAddress
  • Relatively simple, uses the existing GetUnwindInfo implementation.
  • Added docs
• GetGCInfo
  • Uses new datadescriptor RealCodeHeader::GCInfo
  • Added doc explaining how this is found for R2R and jitted code.
  • R2R section still needs work to handle platforms != x86 due to complexities calculating unwind code size.
  • Refactored ReadyToRunJitManager as GetGCInfo, GetUnwindInfo, and GetMethodInfo had very similar implementations.
• GetRelativeOffset
  • Added docs, simple API to extract field off of CodeBlock, similar to GetMethodDesc and GetStartAddress
    Extension IsFunclet
  • Implemented simply in terms of IExecutionManager.StartAddress(cbh) != IExecutionManager.GetFuncletStartAddress(cbh)
  • Added docs

IStackWalk

• Added support for X86 Platform
  • IPlatformAgnosticContext.GetContextForPlatform support x86
  • Added X86 context based on https://github.com/microsoft/clrmd/blob/main/src/Microsoft.Diagnostics.Runtime/DataReaders/Registers/X86Context.cs
• Managed Implementation of X86 GCInfo decoding
  • Based on src/coreclr/tools/aot/ILCompiler.Reflection.ReadyToRun/x86/
• Managed Implementation of X86 Unwinder
  • Based on implementation in gc_unwind_x86.inl
  • GCInfo uses
    • InfoHdr to decode the header. This involves reading an initial header from a lookup table then modifying with a series of instructions.
    • GCArgTable to decode the argument/stack depth table.
    • GCTransition used as part of the GCArgTable decoding.
    • CallPattern to decode common call pattern encodings in the GCArgTable. Uses look up table similar to InfoHdr.
• Added X86FrameHandler
  • The following Frames were verified:
    • SoftwareExceptionFrame
    • InlinedCallFrame
    • TransitionFrames
    • FaultingExceptionFrame
  • Frames not currently verified/implemented:
    • ResumableFrame
    • HijackFrame
    • TailCallFrame

Issues

• SOS can call GetUsefulGlobals API before global pointer data is initialized.

  • Occurs in the SOS.NestedExceptionTest.
  • When building on MSVC, the DAC global table is statically constructed and is available. When building on clang, the table is constructed in EEStartup and probably wouldn't be available when SOS calls.
  • For now, the cDAC assertion around GetUsefulGlobals has been loosened. If the cDAC and the DAC have different HResults, but the same data (usually all 0s), that is acceptable.

• GCInfo Version

  • For JITted code, this is straight forwards, we read from the runtime the GCInfo version.
  • For R2R code, we can read the R2R header to determine the version.
  • Eventually the GCInfo Decoder will need to support future GCInfo versions. Since a Target can have multiple GCInfo versions, I think this should not be a standard cDAC contract. We can use the existing versioning mechanism.

• ILStubType

  • No longer required due to remove x86 ICF special handling #116388
  • This is an enum where the later values can be different depending on FEATURE_INSTANTIATINGSTUB_AS_IL. Currently this PR only needs values before they have different numbering.

  • runtime/src/coreclr/vm/method.hpp

    Lines 2708 to 2734 in 6ab0311

    	enum ILStubType : DWORD
    	{
    	StubNotSet = 0,
    	StubCLRToNativeInterop,
    	StubCLRToCOMInterop,
    	StubNativeToCLRInterop,
    	StubCOMToCLRInterop,
    	StubStructMarshalInterop,
    	StubArrayOp,
    	StubMulticastDelegate,
    	StubWrapperDelegate,
    	#ifdef FEATURE_INSTANTIATINGSTUB_AS_IL
    	StubUnboxingIL,
    	StubInstantiating,
    	#endif
    	StubTailCallStoreArgs,
    	StubTailCallCallTarget,
    	StubVirtualStaticMethodDispatch,
    	StubDelegateShuffleThunk,
    	StubDelegateInvokeMethod,
    	StubAsyncResume,
    	StubLast
    	};

  • For now, we are encoding the enum as a contract constant like other enums defined in method.hpp. Currently we are only using static values, so the runtime did not need to be changed. If we need values later, we can modify the runtime enum to remove the ifdef or add an else block to fill the same number of enum slots.

• JitHalt Debug

  • In the runtime x86 unwinder, behavior in debug builds is different. In some cases, it will skip over a "JIT halt" at the start of a method, only in debug mode. Since the DAC and target runtime will always have the same configuration, the ifdef is really for the target runtime as well. This is not true for the cDAC. Is this check acceptable in release builds? Alternatively, I can add a datadescriptor to check if the target runtime is built in Debug or Release and match the DAC behavior exactly.

  • runtime/src/coreclr/vm/gc_unwind_x86.inl

    Lines 2773 to 2780 in 3aa0c97

    	#ifdef _DEBUG
    	// If the first two instructions are 'nop, int3', then we will
    	// assume that is from a JitHalt operation and skip past it
    	if (methodStart[0] == X86_INSTR_NOP && methodStart[1] == X86_INSTR_INT3)
    	{
    	offset += 2;
    	}
    	#endif

  • Based on discussion, this check is okay to happen in release builds. Modifying the runtime x86 unwinder to remove the _DEBUG check for consistency.

• [cDAC] Implement sign extension for ClrDataAddresses #116222

• X86 GCDecoder RevPInvoke nits #116264

• IExecutionManager.GetGCInfo needs the function entry unwind info, not the unwind info directly correlating to the offset.

• Handle parsing ArgTab correctly when GCInfo header does not have an argTabOffset.

[dotnet-policy-service]

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

[filipnavara]

Currently the runtime looks at the major version to determine what version for R2R code. I think we should parse this, but not support old versions

We recently switched x86 to use funclets which is a major R2R breaking change. I feel that there's no point in supporting anything older, both cDAC and x86/funclets are on the same shipping schedule.

[jkotas]

Is this commented out assert intentional?

[max-charlamb]

Yes. This was something I discovered while running the SOS tests on x86.
SOS can call GetUsefulGlobals API before global pointer data is initialized. When built with MSVC, the DAC global table is statically constructed and is available leading to a successful call. When building on clang, the table is constructed in EEStartup and probably wouldn't be available when SOS calls. Since it would be very difficult (and unnecessary) to match this behavior exactly, for now, I loosened the cDAC assertion around GetUsefulGlobals.

If the cDAC and the DAC have different HResults, but the same data (usually all 0s), that seems acceptable.

I noted it in the PR description but will add a comment explaining why the assertion is loosened.

[max-charlamb]

Added comment

[jkotas]

Nit: I do not think we need to bother maintaining FeatureEHFunclets checks. It should be fine to assume funclets for cdac.

[jkotas]

Thanks

[jkotas]

I think you can delete this constant too

[max-charlamb]

There are a couple other uses of the FeatureEHFunclets flag, I was going to open a different PR to totally remove the datadescriptor if that is okay.

[jkotas]

Ok

[max-charlamb]

#116743 created, to avoid merge conflicts it will fail to build until this PR is merged

[max-charlamb]

/azp run runtime-diagnostics

[azure-pipelines]

Azure Pipelines successfully started running 1 pipeline(s).

[max-charlamb]

/ba-g Failures unrelated to changes. dotnet/dnceng#5904