Several bugs related to enum debugging

[artemmukhin]

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.

[tromey]

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

(lldb) p e2
(q::Enum2) e2 = {
  A = (x = 4, y = 5)
}

Variant disappears

(lldb) p e
(q::Enum::B) e = (1, 2)

I didn't look at the final case yet.

[tromey]

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]

Is "rust-enabled LLDB" just a bash script attaching pretty-printers to the default system LLDB? I realized I should just update rustc to 1.32.0-nightly (and gdb to 8.2) to see the benefits. But I still don't know what version LLDB I should use.

Thank you for your help!

[tromey]

Is "rust-enabled LLDB" just a bash script attaching pretty-printers to the default system LLDB?

Nope, it is the lldb that has the Rust language plugin. It is installable via rustup for macos.

[artemmukhin]

Could you please explain how can I install and use it?
I found the component lldb-preview-x86_64-apple-darwin via rustup component list | grep lldb, ran rustup 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]

Is this it?

Yes. The rust-lldb wrapper will prefer this version of lldb if it is installed. So, just run rust-lldb to get it. You can double-check with rustup-lldb --version to see if "rust-enabled" appears in the output. There is some more info here.

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?

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]

Thanks a lot for a link to "Rust Debugging Quest", I'll monitor the progress of it!

So, just run rust-lldb to get it

I ran it, but got this:

(lldb) r
error: process launch failed: unable to locate debugserver

After export LLDB_DEBUGSERVER_PATH=~/.rustup/toolchains/nightly-x86_64-apple-darwin/lib/rustlib/x86_64-apple-darwin/bin/lldb-server, I got this:

(lldb) r
error: process launch failed: failed to get reply to handshake packet

Could you please help me find a way to use it?

I'm curious why IntelliJ needs its own pretty-printers

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

So, I'm working on a patch to disable the enum pretty-printers, among others.

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]

Could you please help me find a way to use it?

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

The current state of LLDB pretty-printers is poor. The main problem is they don't use synthetic children at all.

Thanks for the info. I'm in favor of fixing this in the Rust repository if at all possible, FWIW.

I'm very glad to hear it and look forward to such updates!

Step 1 is here: #55767

[tromey]

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.