Bug 21466 - better printing of unsized types
Summary: better printing of unsized types
Status: RESOLVED FIXED
Alias: None
Product: gdb
Classification: Unclassified
Component: rust (show other bugs)
Version: unknown
: P2 normal
Target Milestone: 13.1
Assignee: Tom Tromey
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2017-05-07 05:30 UTC by Tom Tromey
Modified: 2022-04-15 17:37 UTC (History)
0 users

See Also:
Host:
Target:
Build:
Last reconfirmed:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Tom Tromey 2017-05-07 05:30:37 UTC
I found this example on reddit
(https://www.reddit.com/r/rust/comments/60ywnb/initializing_a_dynamically_sized_type/)

struct Bar<T: ?Sized> {
    info: u32,
    data: T,
}

type Foo = Bar<[u8]>;

fn main() {
    let x: Box<Bar<[u8; 3]>> = Box::new(Bar { info: 0, data: [1, 2, 3] });
    let y: Box<Foo> = x;
}

I had to add "let z = y" to get debuginfo for "y".
Then running in gdb I get:

(gdb) p *y
$2 = us::Bar<[u8]> {
  info: 0,
  data: 0x7ffff6c1f014
}

... but that doesn't seem very friendly; in fact it seems odd that the
array's address is printed.

Also the ptype output is a bit off:

(gdb) ptype *y
type = struct us::Bar<[u8]> {
  info: u32,
  data: [u8; ],
}


It ought to print "data: [u8]" there.
Comment 1 Tom Tromey 2017-05-21 19:09:37 UTC
Printing the array's address is intentional, see generic_val_print_array.
I suppose the idea is that we can't be sure there's even a single element.
Maybe there's something better the rust code could print here, but
I don't know what that might be at this point.
Comment 2 Sourceware Commits 2017-05-21 23:03:45 UTC
The master branch has been updated by Tom Tromey <tromey@sourceware.org>:

https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=e6cf65f283b8be44014fad0ad0aebfbcc71fceac

commit e6cf65f283b8be44014fad0ad0aebfbcc71fceac
Author: Tom Tromey <tom@tromey.com>
Date:   Sun May 21 17:00:10 2017 -0600

    Print Rust unsized array types a bit more nicely
    
    It's a bit difficult to create an unsized array type in Rust, but if
    you do, right now ptype will show something like "[u8; ]".  It really
    should print "[u8]", though, which is what this patch implements.
    
    This is part of PR 21466.
    
    Built and regtested on x86-64 Fedora 25.  I'm checking this in.
    
    ChangeLog
    2017-05-21  Tom Tromey  <tom@tromey.com>
    
    	PR rust/21466:
    	* rust-lang.c (rust_print_type) <TYPE_CODE_ARRAY>: Print unsized
    	arrays as "[T]", not "[T; ]".
    
    testsuite/ChangeLog
    2017-05-21  Tom Tromey  <tom@tromey.com>
    
    	PR rust/21466:
    	* gdb.rust/unsized.exp: New file.
    	* gdb.rust/unsized.rs: New file.
Comment 3 Tom Tromey 2017-05-21 23:04:17 UTC
I'm leaving this one open until I decide what, if anything, to do
about printing these values.
Comment 4 Tom Tromey 2022-01-24 00:39:40 UTC
I wonder if this helps:
https://github.com/rust-lang/rust/issues/92718
Or maybe it already works.
Comment 5 Tom Tromey 2022-01-24 23:56:25 UTC
> Or maybe it already works.

Definitely does not work yet.
Comment 6 Tom Tromey 2022-03-27 21:22:57 UTC
This works with the 1.61 (currently this is nightly) compiler.
I have a patch.
Comment 7 Sourceware Commits 2022-04-15 17:35:58 UTC
The master branch has been updated by Tom Tromey <tromey@sourceware.org>:

https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=506ec52e8805d8edd538d6bd11750489a8c8bbee

commit 506ec52e8805d8edd538d6bd11750489a8c8bbee
Author: Tom Tromey <tom@tromey.com>
Date:   Fri Mar 25 13:36:53 2022 -0600

    Reimplement Rust slice printing
    
    The current nightly Rust compiler (aka 1.61) added better DWARF
    representation for unsized types.  Fixing this is PR rust/21466; but
    the code is actually the same as what is required to make slice
    printing more useful, which is PR rust/23871.  This patch implements
    this.  I tested this against various Rust compilers: 1.48, current
    stable, current beta, and current nightly.
    
    Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=21466
    Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=23871
Comment 8 Tom Tromey 2022-04-15 17:37:08 UTC
Fixed.