Skip to content

NonZero is not debugable in gdb (anonymous fields can't be accessed) #21948

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
Manishearth opened this issue Feb 4, 2015 · 3 comments
Closed
Labels
A-debuginfo Area: Debugging information in compiled programs (DWARF, PDB, etc.)

Comments

@Manishearth
Copy link
Member

Servo recently switched to NonZero for its smart pointers. This means that our JS structs of the form

struct JSRef<T> {
ptr: *const T,
...
}

became

struct JSRef<T> {
ptr: NonZero<*const T>,
...
}

In the original system, print ref.ptr in gdb would nicely print a typed pointer (something like (struct foo::bar::Baz<Quux>)* 0x12345 IIRC). Now, it gives us simply {0x12345}, and there doesn't seem to be a way to get the inner data out. This is quite annoying since we use these pointers everywhere in the DOM.

The larger issue here I guess is that anonymous fields can't be accessed as an expression in gdb. Perhaps naming them .0, .1 explicitly would work?

cc @michaelwoerister @jdm

@Manishearth Manishearth changed the title NonZero is un-debugable in gdb (anonymous fields can't be accessed) NonZero is not debugable in gdb (anonymous fields can't be accessed) Feb 4, 2015
@jdm jdm added the A-debuginfo Area: Debugging information in compiled programs (DWARF, PDB, etc.) label Feb 4, 2015
@michaelwoerister
Copy link
Member

Maybe this could be solved by adding special support for NonZero in the pretty printers.

bors added a commit that referenced this issue Apr 13, 2015
…chton

This PR makes `rustc` emit field names for tuple fields in DWARF. Formerly there was no way of directly accessing the fields of a tuple in GDB and LLDB since there is no C/C++ equivalent to this. Now, the debugger sees the name `__{field-index}` for tuple fields. So you can type for example `some_tuple_val.__2` to get the third tuple component.
When pretty printers are used (e.g. via `rust-gdb` or `rust-lldb`) these artificial field names will not clutter tuple rendering (which was the main motivation for not doing this in the past).

Solves #21948.
@michaelwoerister
Copy link
Member

Tuple fields should now be accessible in the debugger via the names __0, __1, __2, etc. It's not as nice as .0, .1, etc, but it's the best that debuggers will let us do for the moment.

@Manishearth
Copy link
Member Author

Thanks! 😄

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
A-debuginfo Area: Debugging information in compiled programs (DWARF, PDB, etc.)
Projects
None yet
Development

No branches or pull requests

3 participants