Repository navigation
Several bugs related to enum debugging #55586
Description
I have found some bugs related to enum debug info.
My LLDB version is lldb-1000.0.37 (MacOS), GDB is 8.1.0.20180409-git (Ubuntu).
Here they are:
Variants with the same names
enum Enum1<T> { A(T), B(T) }
enum Enum2 { A { x: i32, y: i32 } }
fn main() {
let e1 = Enum1::A(42);
let e2 = Enum2::A { x: 4, y: 5 };
}
Run LLDB (without pretty-printers):
(lldb) print e2
(test::Enum2) $1 = {
= (RUST$ENUM$DISR = 4, __0 = 5)
}
RUST$ENUM$DISR = 4?
Variant disappears
enum Enum { A, B(i32, i32), C(i32, i32, i32) }
fn main() {
let e = Enum::B(1, 2);
}
Run LLDB (without pretty-printers):
(lldb) print e
(test::Enum) $0 = {
= (RUST$ENUM$DISR = B)
= (RUST$ENUM$DISR = B, __0 = 1, __1 = 2, __2 = 32766)
}
No second variant?
Probably no discriminant
enum Enum { A(i32, i32), B(String, i32), C { x: i32 } }
fn main() {
let e = Enum::B(String::from("abc"), 42);
}
Run GDB + default pretty-printers:
(gdb) print e
File "rustlib/etc/gdb_rust_pretty_printing.py", line 169, in rust_pretty_printer_lookup_function
discriminant_val = rustpp.get_discriminant_value_as_integer(val)
File "rustlib/etc/debugger_pretty_printers_common.py", line 340, in get_discriminant_value_as_integer
variant_val = enum_val.get_child_at_index(0)
File "rustlib/etc/gdb_rust_pretty_printing.py", line 75, in get_child_at_index
child = GdbValue(self.gdb_val[gdb_field])
gdb.error: That operation is not available on integers of more than 8 bytes.
Probably e doesn't contain valid discriminant inside the first variant.
Activity
tromey commentedon Nov 1, 2018
Many problems in this area were fixed by #54004; though to see the benefits you will need the rust-enabled lldb (or gdb 8.2). Here's the results from this combo.
Variants with the same names
Variant disappears
I didn't look at the final case yet.
tromey commentedon Nov 2, 2018
I get an error from the 3rd case when using gdb8.2. Probably when using a rust-enabled gdb or lldb, the enum printers should be disabled. There may be some underlying bug in gdb, though I don't know yet.
artemmukhin commentedon Nov 5, 2018
Is "rust-enabled LLDB" just a bash script attaching pretty-printers to the default system LLDB? I realized I should just update
rustcto1.32.0-nightly(andgdbto 8.2) to see the benefits. But I still don't know what version LLDB I should use.Thank you for your help!
tromey commentedon Nov 5, 2018
Nope, it is the lldb that has the Rust language plugin. It is installable via rustup for macos.
artemmukhin commentedon Nov 6, 2018
Could you please explain how can I install and use it?
I found the component
lldb-preview-x86_64-apple-darwinviarustup component list | grep lldb, ranrustup component add lldb-preview, and then found a new binary file~/.rustup/toolchains/nightly-x86_64-apple-darwin/lib/rustlib/x86_64-apple-darwin/bin/lldb. Is this it?Let me just explain the context. I'm working on the new pretty-printers (now only for LLDB, but then for GDB too): [1], [2]. They will be bundled in the next version of IntelliJ Rust plugin, and later I'm going to create a pull request to Rust. So I don't want to develop it in isolation from the Rust compiler's development to avoid doing unnecessary work. Can I get in touch with you to coordinate the development of debuggers and pretty-printers?
tromey commentedon Nov 6, 2018
Yes. The
rust-lldbwrapper will prefer this version oflldbif it is installed. So, just runrust-lldbto get it. You can double-check withrustup-lldb --versionto see if "rust-enabled" appears in the output. There is some more info here.Definitely.
I'm curious why IntelliJ needs its own pretty-printers. In gdb at least (I'm less familiar with lldb here) the goal was to avoid this sort of duplication.
Anyway, for Rust I plan to disable some pretty-printers when a rust-enabled gdb or lldb is in use. In particular my view is that types that are intrinsic to the language should be supported directly by the debugger; while types that are in the standard library should have a pretty-printer (when needed). So, I'm working on a patch to disable the enum pretty-printers, among others.
artemmukhin commentedon Nov 7, 2018
Thanks a lot for a link to "Rust Debugging Quest", I'll monitor the progress of it!
I ran it, but got this:
After
export LLDB_DEBUGSERVER_PATH=~/.rustup/toolchains/nightly-x86_64-apple-darwin/lib/rustlib/x86_64-apple-darwin/bin/lldb-server, I got this:Could you please help me find a way to use it?
The current state of LLDB pretty-printers is poor. The main problem is they don't use synthetic children at all. Just look at the examples:
Before (only summary):
After (summary + synthetic children):
Some of GDB printers also don't work correctly (e.g. BTree).
I'm very glad to hear it and look forward to such updates! Then I'll get rid of enum/tuple printers and focus on the standard library: collections,
Rc/Arc/Box, and so forth.tromey commentedon Nov 7, 2018
For now you'll need xcode (or some other code-signed
debugserver). See rust-lang/lldb#19. (I haven't made progress on this recently but I have a query out to find out more.)Thanks for the info. I'm in favor of fixing this in the Rust repository if at all possible, FWIW.
Step 1 is here: #55767
Merge #3008
tromey commentedon Nov 15, 2018
I think everything here is fixed -- the rust lldb solves some of the problems, and disabling some pretty-printers for rust-enabled gdb fixed the rest. So if you concur I'd like to close it.
Rollup merge of rust-lang#60826 - ortem:new-dbg-pretty-printers, r=pn…
Auto merge of rust-lang#72357 - ortem:new-dbg-pretty-printers, r=pnkf…