Remove extra x86 unwind from DBI#130011
Open
rcj1 wants to merge 3 commits into
Open
Conversation
Contributor
|
Tagging subscribers to this area: @steveisok, @tommcdon, @dotnet/dotnet-diag |
Contributor
There was a problem hiding this comment.
Pull request overview
This PR removes the DBI-side “unwind one frame ahead” mechanism used to derive an x86 frame pointer, and instead computes the x86 frame pointer inside DAC stackwalking logic (alongside related cleanup of the legacy COM/DDI surface and RS caching state).
Changes:
- Removes the
GetFramePointermethod from the DacDbi COM/DDI surface and the managed legacy cDAC fallback layer. - Simplifies
CordbStackWalkby deleting the “one frame ahead” caching/bookkeeping and relying onGetStackWalkCurrentFrameInfoto provide the needed frame pointer. - Adds x86-specific frame pointer computation in
dacdbiimplstackwalk.cppas part ofGetFramePointerWorker/InitFrameData.
Show a summary per file
| File | Description |
|---|---|
| src/native/managed/cdac/Microsoft.Diagnostics.DataContractReader.Legacy/Dbi/IDacDbiInterface.cs | Removes managed DDI declaration for GetFramePointer. |
| src/native/managed/cdac/Microsoft.Diagnostics.DataContractReader.Legacy/Dbi/DacDbiImpl.cs | Removes managed implementation/fallback for GetFramePointer. |
| src/coreclr/inc/dacdbi.idl | Removes GetFramePointer from the COM interface and updates related comments. |
| src/coreclr/debug/inc/dacdbiinterface.h | Removes GetFramePointer from the native interface contract docs. |
| src/coreclr/debug/di/rsstackwalk.cpp | Deletes one-frame-ahead RS caching/unwind behavior and related error caching. |
| src/coreclr/debug/di/rspriv.h | Removes RS bookkeeping fields tied to one-frame-ahead unwinding. |
| src/coreclr/debug/daccess/dacdbiimplstackwalk.cpp | Introduces x86 frame pointer computation and uses it when filling Debugger_STRData.fp. |
| src/coreclr/debug/daccess/dacdbiimpl.h | Removes GetFramePointer declaration from DAC DBI implementation header. |
Copilot's findings
- Files reviewed: 8/8 changed files
- Comments generated: 4
This was referenced Jun 30, 2026
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
In the DBI, we unwind the stack walk one frame ahead when we need to generate a frame pointer on x86. This is because the frame pointer is derived from the caller context. I replaced this with inline physical unwind, and derived the frame pointer from the formula here:
runtime/src/coreclr/vm/stackwalk.cpp
Line 375 in 46b72c7
We had unwound one ahead when we are on a runtime-unwindable or managed frame. In either case, we would unhijack the runtime-unwindable stub, or do one physical unwind, plus however many unwinds it took to get us to the next managed frame. Here, we stop after the first step to calculate the frame pointer. This is a behavioral change, if the caller is non-managed, but it should produce if anything more accurate / strictly ordered frame boundaries, especially in use cases such as
GetStackRange.The goal of this PR is to hide as much of the platform-specific details behind DacDbi as possible - we will no longer have to do a custom adjustment in DBI just for X86 targets. In addition, we consolidate the retrieval of general stack frame info into the DacDbi API
GetStackWalkCurrentFrameInfo.