[cDAC] 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();

For more infomation on stackwalking, see StackWalk.md

Work Items

• 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.

• Convert dynamically linked native libs to statically linked 113627

• Fetching initial thread context - [cDAC] Implement core stackwalking #111759

• cDAC native interop to call unwinders - [cDAC] Implement core stackwalking #111759

• Automate SOS tests to run against cDAC in CI

  • Establish runtime-diagnostics pipeline #113169
  • [cDAC] Add support to run SOS tests against the cDAC diagnostics#5350
  • Cross-platform run in ADO

• [cDAC] Implement ClrDataAccess::GetFrameName #112274

• [cDAC] Support building and linking cross targeted cDAC unwinders on all platforms #112272

• [cDAC] Implement support for filtering on IXCLRDataTask::CreateStackWalk #112277

• On ARM64 Linux (maybe other platforms) the contract descriptor is not included in Heap minidumps.

• Create cDAC entrypoint same as DAC CLRDataCreateInstance #112583

Lower Priority Items

• Support flags in IXCLRDataTask.CreateStackWalk #112366 - Not used in !analyze
• [cDAC] Implement IXCLRDataStackWalk::Request support for CLRDATA_REQUEST_REVISION and CLRDATA_STACK_WALK_REQUEST_SET_FIRST_FRAME #112275 - Not used in !analyze

x64 and arm64 specific Work Items

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

• Create managed data structures for windows system CONTEXT on x64 and arm64. [cDAC] Implement core stackwalking #111759
  • 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 on x64 and arm64 - [cDAC] Implement core stackwalking #111759
• Design cDAC level API to expose stack walking #111734 - [cDAC] Implement core stackwalking #111759
• Implement Contract level APIs that will be used for managed stack walking through the IXCLRDataStackWalk - [cDAC] Implement core stackwalking #111759
• Support linking native libraries to cDAC on non-Windows platforms #112416

Lower Priority Items

• [cDAC] Implement ReplacePatchesInHostMemory in amd64 unwinder #112273

x86 and arm32 specific Work Items

• Create managed data structures for windows system CONTEXT on x86 and arm32
• Support Native Unwinders on x86 and arm32
• [cDAC] Stackwalking support all Frame types #114019
• CodeInfo -> Decode GCHdrInfo
• CodeInfo -> Get SavedMethodCode
• CodeInfo -> Get RelativeOffset
• CodeInfo -> Get FuncletStartAddress
• CodeInfo -> Get IsFunclet

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.