[cDAC] Contract implementations needed for managed stack walking

[max-charlamb]

Issue is in progress and incomplete

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();

Work Items

• Allowing Fetching initial thread context
  • Pass ICorDebugDataTarget into the cDAC to facilitate extending Target with GetThreadContext(...)
  • Implement fallback using Frame?

    runtime/src/coreclr/debug/daccess/dacdbiimpl.cpp

    Lines 5628 to 5659 in 4822cc0

    	HRESULT hr = m_pTarget->GetThreadContext(pThread->GetOSThreadId(),
    	pContextBuffer->ContextFlags,
    	sizeof(DT_CONTEXT),
    	reinterpret_cast<BYTE *>(pContextBuffer));
    	if (hr == E_NOTIMPL)
    	{
    	// GetThreadContext is not implemented on this data target.
    	// That's why we have to make do with context we can obtain from Frames explicitly stored in Thread object.
    	// It suffices for managed debugging stackwalk.
    	REGDISPLAY tmpRd = {};
    	T_CONTEXT tmpContext = {};
    	FillRegDisplay(&tmpRd, &tmpContext);
    	// Going through thread Frames and looking for first (deepest one) one that
    	// that has context available for stackwalking (SP and PC)
    	// For example: RedirectedThreadFrame, InlinedCallFrame, HelperMethodFrame, CLRToCOMMethodFrame
    	Frame *frame = pThread->GetFrame();
    	while (frame != NULL && frame != FRAME_TOP)
    	{
    	frame->UpdateRegDisplay(&tmpRd);
    	if (GetRegdisplaySP(&tmpRd) != 0 && GetControlPC(&tmpRd) != 0)
    	{
    	UpdateContextFromRegDisp(&tmpRd, &tmpContext);
    	CopyMemory(pContextBuffer, &tmpContext, sizeof(*pContextBuffer));
    	pContextBuffer->ContextFlags = DT_CONTEXT_CONTROL;
    	return;
    	}
    	frame = frame->Next();
    	}
    	// It looks like this thread is not running managed code.
    	ZeroMemory(pContextBuffer, sizeof(*pContextBuffer));

• Create managed data structures for windows system CONTEXT and libunwind CONTEXT.
• Marshall frame related information

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