[cDAC] Contract implementations needed for managed stack walking

[max-charlamb]

In order to support SOS !analyze the cDAC must implement stack walking through the following APIs:

IXCLRDataTask::CreateStackWalk();
IXCLRDataStackWalk::Request(DACSTACKPRIV_REQUEST_FRAME_DATA, ...);
IXCLRDataStackWalk::GetContext();
IXCLRDataStackWalk::Next();

To create a full managed stack walk, two types of stacks must be read. Call frames on the stack and capital "F" Frames representing runtime unmanaged frames. The Frames are pushed and popped to a linked list on the runtime Thread object. For more information see: BOTR Stack Walking.

To unwind managed call frames, we delegate to the existing native unwinding code. For managed frames, all platforms use the Windows unwind logic and codes. For native call frames, this is platform specific. Since we only care about managed call frames, all unwinding uses the Windows implementation under src/coreclr/unwinder/. See the following for more information:

• Windows x64
• Windows ARM64

Simplified Stack Unwinding Algorithm

1. Read thread context.
2. If the current IP is in managed code, use Windows style unwinding until the current IP is not managed code.
3. For each capital 'F' Frame from deepest to shallowest:
   1. If the Frame contains a context, read the SP/IP. Otherwise skip this frame.
   2. If the IP is in managed code, use Windows style unwinding until the current IP is not managed code.

Work Items

Initial implementation will focus on x64 stack walking before expanding to all supported platforms.

• Covert Frames to use an Enum intead of vptr #111875 - Use enum for frametype not v table #112166
  • Required to identify Frames through datadescriptors at compile time.
• Support all Frames with NeedsUpdateRegDisplay()==true
  • ResumableFrame
    • Stores a PTR_CONTEXT
  • TransitionFrame
    • Stores data in TransitionBlock
    • Tested with PrestubMethodFrame
    • Testing notes: Happens when JITing, set breakpoint during JIT to create a dump.
  • FaultingExceptionFrame
    • On x86, stores specific registers, otherwise stores a T_CONTEXT
    • Testing notes: Set breakpoint in ThrowControlForThread after it calls InitAndLink. Invoke with a two threaded process where one thread is doing work (loop checking volatile variable) and is cancelled using the following API: Implement ControlledExecution API #71661
    • Invokation through: RedirectForThrowControl2 ASM macro. THROW_CONTROL_FOR_THREAD_FUNCTION
  • SoftwareExceptionFrame - [cDAC] Implement basic stackwalking #111759
    • Stores a copy of T_CONTEXT
  • FuncEvalFrame (only relevant for debugging, may not be needed)
    • Debugger test app use immediate window to call Console.ReadLine() while it is executing create a dump. Use OS to create a dump (or WinDBG as a non-invasive attach on the debugged process).
  • HelperMethodFrame
    • Stores LazyMachState
  • HijackFrame
    • Set native breakpoint in the GC have second thread doing continuous CPU intensive work (loop checking volatile bool).
  • InlinedCallFrame - [cDAC] Implement basic stackwalking #111759
    • Stores IP, SP, and FP directly.
  • TailCallFrame (Windows x86 only)
• Expose ICorDebugDataTarget::GetPlatform - [cDAC] Implement basic stackwalking #111759
  • See example usage in SOS
• Fetching initial thread context - [cDAC] Implement basic stackwalking #111759
• Create managed data structures for windows system CONTEXT.
  • AMD64 - [cDAC] Implement basic stackwalking #111759
  • ARM64 - [cDAC] Implement basic stackwalking #111759
  • i386
  • ARM
  • Can use CLRMD context's as reference: https://github.com/microsoft/clrmd/blob/fa787489e504e36549cbebac6b4d1e0f79fa80ea/src/Microsoft.Diagnostics.Runtime/DataReaders/Registers/Amd64Context.cs
• Support Native Unwinders
  • AMD64 - [cDAC] Implement basic stackwalking #111759
  • ARM64 - [cDAC] Implement basic stackwalking #111759
  • i386
  • ARM
• Convert dynamically linked native libs to statically linked
• cDAC native interop to call unwinders - [cDAC] Implement basic stackwalking #111759
• [cDAC] Support building and linking cross targeted cDAC unwinders on all platforms #112272
• Design cDAC level API to expose stack walking #111734 - [cDAC] Implement basic stackwalking #111759
• Implement Contract level APIs that will be used for managed stack walking through the IXCLRDataStackWalk - [cDAC] Implement basic stackwalking #111759
• Automate SOS tests to run against cDAC in CI.
  • Cross-platform run in ADO
• [cDAC] Implement ReplacePatchesInHostMemory in amd64 unwinder #112273
• [cDAC] Implement ClrDataAccess::GetFrameName #112274
• [cDAC] Implement IXCLRDataStackWalk::Request support for CLRDATA_REQUEST_REVISION and CLRDATA_STACK_WALK_REQUEST_SET_FIRST_FRAME #112275
• [cDAC] Implement support for filtering on IXCLRDataTask::CreateStackWalk #112277
• Support flags in IXCLRDataTask.CreateStackWalk #112366
• Support linking native libraries to cDAC on non-Windows platforms #112416
• Create cDAC entrypoint same as DAC CLRDataCreateInstance #112583
• Create test leg in runtime repo for cDAC verification.
• On ARM64 Linux (maybe other platforms) the contract descriptor is not included in Heap minidumps.

Paths Forwards

1. Independent Work
   1. Complete Frame support
   2. Cross-platform building
   3. Filtering flags
   4. ARM32/x86 Support. Should wait for x86 to use funclets before adding support?
2. SOS Work
   1. Flip to invoke cDAC directly, allow testing on platforms where the cross-DAC is not available.
   2. Automated testing
   3. Testing with customer dumps - Include all required datadescriptors ASAP to allow verification on customer dumps.
3. Threat Model

[dotnet-policy-service]

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

[jkoritzinsky]

I would recommend the following approach for the context:

T_CONTEXT should be an opaque (to cdac) struct with a defined size in the data descriptor for the current platform. If any of the registers are used as part of stackwalking (likely the instruction pointer, stack pointer, frame pointer), there should be well-known field names for those concepts, which each runtime's data descriptor maps to the right registers.

If it was desired to map all registers and offsets to manually assign them out at the cDAC boundary, the data descriptor could have all of the fields for all of the register names for each platform, and then the cdac would do an if-else chain to dynamically read the field offsets and assign them to the buffer depending on the target runtime's architecture. However, even in this case, I'd recommend having well-known names for the above-mentioned registers if there's any contract implementation or logic that uses them as it makes it easier to implement the algorithms with less platform-specific goo.