You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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?
The text was updated successfully, but these errors were encountered:
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
added
the
A-debuginfo
Area: Debugging information in compiled programs (DWARF, PDB, etc.)
label
Feb 4, 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.
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.
Servo recently switched to NonZero for its smart pointers. This means that our JS structs of the form
became
In the original system,
print ref.ptr
ingdb
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
The text was updated successfully, but these errors were encountered: