-
Notifications
You must be signed in to change notification settings - Fork 12.8k
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
Consider having special debugger pretty printers/handling for Unique/Shared/NonZero #29392
Comments
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:
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 |
I looked at this today. Upstream output is more or less the same, just more clear that pointer points to a tuple.
Dereferencing still needs a lot of typing, but it's now Rust syntax at least:
For |
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 |
…rk-Simulacrum Add GDB/LLDB pretty-printers for NonZero types Add GDB/LLDB pretty-printers for `NonZero` types. These pretty-printers were originally implemented for IntelliJ Rust by `@Kobzol` in intellij-rust/intellij-rust#5270. Part of rust-lang#29392.
…sleywiser Add GDB/LLDB pretty-printers for NonZero types Add GDB/LLDB pretty-printers for `NonZero` types. These pretty-printers were originally implemented for IntelliJ Rust by `@Kobzol` in intellij-rust/intellij-rust#5270. Part of rust-lang#29392.
…sleywiser Add GDB/LLDB pretty-printers for NonZero types Add GDB/LLDB pretty-printers for `NonZero` types. These pretty-printers were originally implemented for IntelliJ Rust by ``@Kobzol`` in intellij-rust/intellij-rust#5270. Part of rust-lang#29392.
…sleywiser Add GDB/LLDB pretty-printers for NonZero types Add GDB/LLDB pretty-printers for `NonZero` types. These pretty-printers were originally implemented for IntelliJ Rust by ``@Kobzol`` in intellij-rust/intellij-rust#5270. Part of rust-lang#29392.
…sleywiser Add GDB/LLDB pretty-printers for NonZero types Add GDB/LLDB pretty-printers for `NonZero` types. These pretty-printers were originally implemented for IntelliJ Rust by ```@Kobzol``` in intellij-rust/intellij-rust#5270. Part of rust-lang#29392.
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.)The text was updated successfully, but these errors were encountered: