[Debug Info] Generate typedef nodes for ptr/ref types (and msvc arrays) #144394
Conversation
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
rustbot
added
A-LLVM
|
oh yeah, i'm not sure if we even run the debuginfo test suite anymore? But if we do, this is gonna fail a lot of those tests (in a good way). I can get that cleaned up if/when those failures happen. |
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
|
Ah, so we do still run the debuginfo tests. One notable problem is that gdb method calls via the All the other failures were just minor considerations for "unwrapping" the typedef into its actual type. |
|
r? @wesleywiser or reassign to someone else who knows debuginfo well |
|
|
6 tasks
|
☔ The latest upstream changes (presumably #146666) made this pull request unmergeable. Please resolve the merge conflicts. |
Walnut356
force-pushed
the
msvc_typedef
branch
from
4b1cdeb to
6f0e667
Compare
|
This PR was rebased onto a different master commit. Here's a range-diff highlighting what actually changed. Rebasing is a normal part of keeping PRs up to date, so no action is needed—this note is just to help reviewers. |
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
Walnut356
force-pushed
the
msvc_typedef
branch
from
85c461b to
74fa455
Compare
|
The job Click to see the possible cause of the failure (guessed by this bot) |
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.
This kills like 17 birds with 1 stone. It allows displaying the proper
&/&mut/*const/*muttype name for*-gnutargets, and fixes a bunch of issues with visualizing*-msvctargets.In short, none of the debuggers (in their current states) respect the "name" field that is passed to
LLVMRustDIBuilderCreatePointerType. That field does appear in theDWARFdata, but GDB and LLDB don't care.This patch wraps the pointer nodes (and msvc array type) in a typedef before finalizing them. Worth noting, this typedef trick is already being used for
*-msvcprimitive types.*-gnuMainly fixes type-name output. Screenshots should be self-explanatory.
GDB
GDB by default hard-codes pointer types to
*mut. This "fixes" that without requiring a code change in GDB, but that's mostly just a happy side effect.LLDB
TypeSystemClangignores thenamefield of the pointer in theDWARFinfo. Using a typedef sidesteps that deficiency. We could maybe modifyTypeSystemClangso this isn't necessary, but since it relies onclang(read: c/c++) compiler type representations under the hood, I'm not sure if pointers can have names and it's not really reasonable to change clang itself to accommodate rust.*-msvcAs opposed to
DWARF, thenamefield does not exist anywhere in thePDBdata. There are 2 reasons for thisPointer nodes do not contain a name field
Primitive types are unique, special nodes that have an additional unique, special representation for pointer-to-primitive
The issue with this is with container types, for example
Vec.Vec<T>'s heap pointer is not a*mut T, it's a*mut u8that is cast to aTwhen needed using (more or less)PhantomData<T>. From the type's perspective,Tonly "exists" in the generic parameters. That means the debugger, working from the type's perspective, must look it up by name, (e.g.Vec<ref$<u8> >must look up the string "ref$<u8>").Since those type names aren't in the PDB data, the lookup fails, the debugger cannot cast the heap pointer, and thus cannot visualize the elements of the container.
In LLDB, the sole arbiter of "what types exist" when doing a type lookup is the PDB data itself. I'm sure the
msdiaworks the same way, but LLDB's native PDB parser checks the type stream, and any pointer-node-to-Tis formatted C-style asT *. This problem also affects Microsoft's debugger.array$<T,N>also needs a typedef, as arrays have a bespoke node whose "name" field is also ignored in favor of the C-style format (e.g.T[N]). If you use Visual Sudio's natvis diagnostics logging, you can see errors such as this:LLDB (via CodeLLDB)
CDB via Visual Studio 2022
CDB via C/C++ extension in Visual Studio Code
The output is identical to Visual Studio, but I want to make a special note because i had to jump through a few hoops to get it to work correctly. Built with stable, it worked the same as the "Before" image from Visual Studio, but built with the patched compiler the
Vecvisualizer wasn't working.Clearly based on the Visual Studio "After" screenshot, the natvis files still work. If you binary-patch the extension so that it outputs verbose logging info it appears it never even tried to load
liballoc.natvisfor some reason?I manually placed the natvis files in
C:\Users\<USER>\.vscode\extensions\ms-vscode.cpptools-1.26.3-win32-x64\debugAdapters\vsdbg\bin\Visualizers\and it worked fine so iunno. Probably worth someone else testing too. Might also be because I'm only using a stage1 build instead of a full toolchain install? I'm not sure.Alternatives
I tried some fiddling with using the
referencedebug info node (which does have a valid counterpart in bothDWARFandPDB). The issue is that LLDB usesTypeSystemClang, which is very C/C++-oriented. In Rust, references are borrowing pointers. In C++ references are not objects, they are not guaranteed to have a representation at run-time. That means no array-of-refs, no ref-to-ref, no pointer-to-ref. LLDB seems to interpret ref-to-ref incorrectly. That can be worked around but the hack necessary for that is heinous and infects the visualizers too. It also means without the visualizers, the type-name output is sorta worse than it is now.