Open huonw opened 9 years ago
Filtering out NonZero and Unique in the pretty printers should be doable I think. We already have special handling for Vec<> and String, for example.
Changing how GDB parses and evaluates expressions is a different thing though. There may be some way to make this work, but doing it cleanly involves going into GDB's rather messy C internals, as far as I know.
As a side note: It seems that LLDB is starting to support language plugins. A real Rust plugin would make it possible to support all of the above and a lot more :)
.
OK, unfortunately this turns out to be way harder to do in GDB than expected. Due to how GDB's pretty printing API is structured, it's not possible filter out intermediate data structure nesting levels (like a NonZero field) without this level still leaving some kind of artifact in the rendered string:
// This ...
struct WithNonZero {
a: NonZero<u32>
}
// ... is rendered as this:
WithNonZero = {a = = { = 9}}
At least the above is the best thing I managed and I tried various different approaches.
The only way to get arround this problem is to have pretty printers for every type, even primitive ones. But then one loses the ability to influence how these are printed. E.g. one can't force integers to be printed as hexadecimals anymore, as can be done with print/x
. That's pretty bad and personally I think that's too big a tradeoff.
I looked at this today.
Upstream output is more or less the same, just more clear that pointer points to a tuple.
(gdb) p f
$1 = u::Foo {
ptr: core::ptr::Unique<u::Bar> {
pointer: core::nonzero::NonZero<*const u::Bar> (
0x7fffffffe198
),
_marker: core::marker::PhantomData<u::Bar>
}
}
Dereferencing still needs a lot of typing, but it's now Rust syntax at least:
(gdb) p *f.ptr.pointer.0
$6 = u::Bar {
y: 10
}
For print *f.ptr
-- I think making that work in gdb would require gdb knowing that the type implements Deref
(currently not in the DWARF). And, then it might also require a non-inlined copy of the appropriate function. Adding the xmethod support would be another approach here.
Visited during wg-debugging triage. There seems to be two different parts to this issue:
The second part is quite a bit more complicated than the first and also relates to ongoing discussions the wg has had with regards to how we want to provider better support for debuggers in general.
The first part (adding pretty printers) shouldn't be too difficult. We already have NatVis ones here and so we just need to add pretty printers to the appropriate Python scripts here and debuginfo tests to cover them. Tagging as E-medium
for the first part.
A debugger is particularly useful for diagnosing problems in unsafe code, and these types appear reasonably often there. Currently they're printed in a rather ugly way:
Compiling with
rustc -g unique.rs
and usingrust-gdb unique
to break on thedrop(f)
line allows one to printf
:Pretty much the only thing that's even slightly interesting there is the
0x7fffffffdef8
and maybe theunique::Bar
, the layers ofNonZero
andPhantomData
are just noise. (And even the raw address is pretty useless, and the type is often obvious from context.)Also, the only way to examine what the pointer points to is to do a pile of field accesses, like:
In the best case, it'd be great if
*f.ptr
could work. (Also,f.ptr.pointer.__0[x]
being writtenf.ptr[x]
, for when theUnique
is representing an array.)(I guess there may be other standard library types to consider in a similar context: making
rust-gdb
handle them even more nicely.)