[Bug rust/23322] New: gdb can't display Option<NonNull<T>> values

[mh-sourceware at glandium dot org]

https://sourceware.org/bugzilla/show_bug.cgi?id=23322

Bug ID: 23322
Summary: gdb can't display Option<NonNull<T>> values
Product: gdb
Version: 8.0
Status: UNCONFIRMED
Severity: normal
Priority: P2
Component: rust
Assignee: unassigned at sourceware dot org
Reporter: mh-sourceware at glandium dot org
CC: tromey at sourceware dot org
Target Milestone: ---

Consider the following rust source:

use std::ptr::NonNull;

fn test(p: Option<NonNull<usize>>) {
println!("{:?}", p);
}

fn test2(p: Option<&usize>) {
println!("{:?}", p);
}

fn test3(p: NonNull<usize>) {
println!("{:?}", p);
}

fn main() {
let mut foo = 42usize;
test(NonNull::new(&mut foo));
test2(Some(&foo));
test3(NonNull::new(&mut foo).unwrap());
}

Compiled with `rustc +nightly foo.rs -C debuginfo=2`.

Run under gdb, and break on foo::test, foo::test2 and foo::test3:

(gdb) break foo::test
Breakpoint 1 at 0x6235: file foo.rs, line 4.
(gdb) break foo::test2
Breakpoint 2 at 0x62d5: file foo.rs, line 8.
(gdb) break foo::test3
Breakpoint 3 at 0x6375: file foo.rs, line 12.
(gdb) r
Starting program: /tmp/foo
[Thread debugging using libthread_db enabled]
Using host libthread_db library "/lib/x86_64-linux-gnu/libthread_db.so.1".

Breakpoint 1, foo::test (p=...) at foo.rs:4
4 println!("{:?}", p);
(gdb) print p
$1 = <error reading variable>
(gdb) cont
Continuing.
Some(0x7fffffffdf18)

Breakpoint 2, foo::test2 (p=...) at foo.rs:8
8 println!("{:?}", p);
(gdb) print p
$2 = core::option::Option<&usize>::Some(0x7fffffffdf18)
(gdb) cont
Continuing.
Some(42)

Breakpoint 3, foo::test3 (p=...) at foo.rs:12
12 println!("{:?}", p);
(gdb) print p
$3 = core::ptr::NonNull<usize> {pointer: core::nonzero::NonZero<*const usize>
(0x7fffffffdf18)}

gdb is able to properly display `Option<&usize>`, which has the same memory
layout as `Option<NonNull<usize>>` and `NonNull<usize>`, but not
`Option<NonNull<usize>>`.

with `set lang c++`, this is what the `Option<NonNull<usize>>` value looks
like:

$4 = {RUST$ENCODED$ENUM$0$None = {::(void) = {pointer = {::(void) =
0x7fffffffdf18}}}}

[tromey at sourceware dot org]

https://sourceware.org/bugzilla/show_bug.cgi?id=23322

Tom Tromey <tromey at sourceware dot org> changed:

What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |NEW
Last reconfirmed| |2018-06-21
Ever confirmed|0 |1

--- Comment #1 from Tom Tromey <tromey at sourceware dot org> ---
This is a debuginfo regression in rustc caused by the newer
enum layout optimizations. For details see:

https://github.com/rust-lang/rust/issues/32920

Another example here: https://github.com/rust-lang/rust/issues/46173

I've got patches for this (the prerequisite is pending, see
https://github.com/rust-lang/llvm/pull/118), but I've been reluctant
to land these in the short term because they break all enum
debugging for un-updated debuggers. (gdb is ready for the new
output though.)

Maybe part of this bug could be worked around in gdb, so I'm
going to leave this open to think about it. For that part see the
llvm bug: https://bugs.llvm.org/show_bug.cgi?id=36654

[tromey at sourceware dot org]

https://sourceware.org/bugzilla/show_bug.cgi?id=23322

Tom Tromey <tromey at sourceware dot org> changed:

What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |RESOLVED
Resolution|--- |OBSOLETE

--- Comment #2 from Tom Tromey <tromey at sourceware dot org> ---
This was fixed in rustc by https://github.com/rust-lang/rust/pull/54004,
so I'm marking it as obsolete.