Skip to content
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

Open
huonw opened this issue Oct 27, 2015 · 4 comments
Labels
A-debuginfo Area: Debugging information in compiled programs (DWARF, PDB, etc.) C-feature-request Category: A feature request, i.e: not implemented / a PR. E-medium Call for participation: Medium difficulty. Experience needed to fix: Intermediate. P-low Low priority T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. T-dev-tools Relevant to the dev-tools subteam, which will review and decide on the PR/issue.

Comments

@huonw
Copy link
Member

huonw commented Oct 27, 2015

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:

#![feature(unique)]
use std::ptr::Unique;

struct Bar { y: u8 }
struct Foo {
    ptr: Unique<Bar>,
}
fn main() {
    let mut x = Bar { y: 10 };
    unsafe {
        let f = Foo { ptr: Unique::new(&mut x) };

        drop(f);
    }
}

Compiling with rustc -g unique.rs and using rust-gdb unique to break on the drop(f) line allows one to print f:

(gdb) break unique.rs:13
(gdb) r
...
(gdb) p f
$1 = Foo = {ptr = Unique<unique::Bar> = {pointer = NonZero<*const unique::Bar> = {0x7fffffffdef8}, _marker = PhantomData<unique::Bar>}}

Pretty much the only thing that's even slightly interesting there is the 0x7fffffffdef8 and maybe the unique::Bar, the layers of NonZero and PhantomData 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:

(gdb) p *f.ptr.pointer.__0
$2 = Bar = {y = 10 '\n'}

In the best case, it'd be great if *f.ptr could work. (Also, f.ptr.pointer.__0[x] being written f.ptr[x], for when the Unique 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.)

@huonw huonw added the A-debuginfo Area: Debugging information in compiled programs (DWARF, PDB, etc.) label Oct 27, 2015
@michaelwoerister
Copy link
Member

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 :).

@michaelwoerister
Copy link
Member

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.

@brson brson added I-wishlist P-low Low priority labels Apr 4, 2017
@tromey
Copy link
Contributor

tromey commented May 7, 2017

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.

@alexcrichton alexcrichton added T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. T-dev-tools Relevant to the dev-tools subteam, which will review and decide on the PR/issue. and removed T-tools T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. labels May 22, 2017
@Mark-Simulacrum Mark-Simulacrum added C-feature-request Category: A feature request, i.e: not implemented / a PR. and removed I-wishlist labels Jul 24, 2017
@wesleywiser
Copy link
Member

Visited during wg-debugging triage. There seems to be two different parts to this issue:

  1. Pretty printers for these types.
  2. Debugger integration with expression evaluation that treats these types more like transparent wrappers.

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.

@wesleywiser wesleywiser added the E-medium Call for participation: Medium difficulty. Experience needed to fix: Intermediate. label Jun 20, 2022
matthiaskrgr added a commit to matthiaskrgr/rust that referenced this issue Jun 26, 2022
…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.
JohnTitor added a commit to JohnTitor/rust that referenced this issue Aug 23, 2022
…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.
JohnTitor added a commit to JohnTitor/rust that referenced this issue Aug 24, 2022
…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.
matthiaskrgr added a commit to matthiaskrgr/rust that referenced this issue Aug 28, 2022
…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.
matthiaskrgr added a commit to matthiaskrgr/rust that referenced this issue Aug 28, 2022
…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.
@Noratrieb Noratrieb added the T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. label Apr 5, 2023
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.) C-feature-request Category: A feature request, i.e: not implemented / a PR. E-medium Call for participation: Medium difficulty. Experience needed to fix: Intermediate. P-low Low priority T-compiler Relevant to the compiler team, which will review and decide on the PR/issue. T-dev-tools Relevant to the dev-tools subteam, which will review and decide on the PR/issue.
Projects
None yet
Development

No branches or pull requests

8 participants