[cDAC] Contract implementations needed for managed stack walking

[max-charlamb]

Issue is in progress and incomplete

To create a full managed stack walk, two types of stacks must be read. Call frames on the stack and capital "F" Frames which represent runtime unmanaged frames. The Frames are stored through a linked list on the runtime thread data structure. For more information see: BOTR Stack Walking.

To unwind call frames, there are several techniques used across different architectures. Because this is architecture/platform specific it is easier to delegate to libunwind/current implementation in the runtime. For more info on platform specific unwinding:

• Windows x64
• Windows ARM64
• Non-Windows

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 Windows x64 stack walking before expanding to all supported platforms.

Frame Walking

• Marshall Frame related information
• Covert Frames to use an Enum to differentiate values. This benefits the runtime by reducing the memory usage of Frames as well as allowing the cDAC datadescriptor to be a compile time constant. While making this change, the GSCookies can be removed from the Frames. They protected the Vptr to prevent arbitrary code execution which won't be possible after removing the Vptr.

Managed Stack Walking

• Expose ICorDebugDataTarget::GetPlatform. See example usage in SOS
• Fetching initial thread context
  • Pass ICorDebugDataTarget into the cDAC to facilitate getting thread context through ICorDebugDataTarget::GetThreadContext
• Create managed data structures for windows system CONTEXT and libunwind CONTEXT.
  • AMD64
  • ARM64
  • i386
  • ARM
  • Can use CLRMD context's as reference: https://github.com/microsoft/clrmd/blob/fa787489e504e36549cbebac6b4d1e0f79fa80ea/src/Microsoft.Diagnostics.Runtime/DataReaders/Registers/Amd64Context.cs
• Compile and link together all architecture unwinders
  • AMD64
  • ARM64
  • i386
  • ARM
• cDAC native interop to call unwinders
  • AMD64
  • ARM64
  • i386
  • ARM

Putting in together

• Design cDAC level API to expose stack walking #111734
  • Implement Contract level APIs that will be used for managed stack walking through the IXCLRDataStackWalk object:

// APIs used by SOS
IXCLRDataTask::CreateStackWalk();
IXCLRDataStackWalk::Request(DACSTACKPRIV_REQUEST_FRAME_DATA, ...);
IXCLRDataStackWalk::GetContext();
IXCLRDataStackWalk::Next();

• Implement ReplacePatchesInHostMemory in x64 Unwinder for cDAC.
• On ARM64 Linux (maybe other platforms) the contract descriptor is not included in Heap minidumps.

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