[Bug rust/25048] FAIL: gdb.rust/simple.exp: print k

tromey at sourceware dot org sourceware-bugzilla@sourceware.org
Fri Oct 4 02:54:00 GMT 2019


--- Comment #3 from Tom Tromey <tromey at sourceware dot org> ---
I think this turns out to be a bug in the Rust compiler.

My guess is that the distro is using a relatively recent version of
Rust but a somewhat older version of LLVM, from before the
DW_TAG_variant patches landed.  However, I don't really recall which
version of Rust fixed this stuff.

Anyway, in this case, the Rust compiler will emit a legacy encoding of
enums.  In the DWARF from this test:

     <2><3a38>: Abbrev Number: 20 (DW_TAG_union_type)
        <3a39>   DW_AT_name        : (indirect string, offset: 0x3037):
        <3a3d>   DW_AT_byte_size   : 16
        <3a3e>   DW_AT_alignment   : 8
     <3><3a3f>: Abbrev Number: 6 (DW_TAG_member)
        <3a40>   DW_AT_name        : (indirect string, offset: 0x29f5):
        <3a44>   DW_AT_type        : <0x3a4b>
        <3a48>   DW_AT_alignment   : 8
        <3a49>   DW_AT_data_member_location: 0
     <3><3a4a>: Abbrev Number: 0
     <2><3a4b>: Abbrev Number: 5 (DW_TAG_structure_type)
        <3a4c>   DW_AT_name        : (indirect string, offset: 0x2a11): Thebox
        <3a50>   DW_AT_byte_size   : 16
        <3a51>   DW_AT_alignment   : 8
     <3><3a52>: Abbrev Number: 6 (DW_TAG_member)
        <3a53>   DW_AT_name        : (indirect string, offset: 0x670): __0
        <3a57>   DW_AT_type        : <0x3957>
        <3a5b>   DW_AT_alignment   : 1
        <3a5c>   DW_AT_data_member_location: 8

There's a comment in dwarf2read.c that explains this (search for
"RUST$ENCODED"), but the gist is that "RUST$ENCODED$ENUM$0$Nothing"
means that field 0 is both a pointer and a discriminant, and if the
value is 0, then the enum is just a data-less variant named "Nothing".

However, if you look here you'll see that field 0 has byte offset 8
and alignment 1... following the type reference:

     <1><3957>: Abbrev Number: 22 (DW_TAG_base_type)
        <3958>   DW_AT_name        : (indirect string, offset: 0x2561): u8
        <395c>   DW_AT_encoding    : 7  (unsigned)
        <395d>   DW_AT_byte_size   : 1

Oops!  The Rust compiler told gdb the wrong slot.

So, this is a bug in the legacy encoding code.  Maybe I broke it when
I wrote this stuff... though I recall quite strongly testing
everything in multiple combinations, so hopefully I did that right and
it's just that something broke here later on.

I tend to think gdb should not do anything about this.  It seems
somewhat difficult to work around.  Like, maybe we could try sorting
the fields by offset and hoping that works?  It seems iffy to me.

The very best thing to do is make sure the distro is using a
new-enough LLVM.  Failing that, I guess you could open a bug against
Rust; though TBH I would be surprised if anyone wanted to fix a bug in
a legacy encoding that is hopefully slated for removal.

If this all sounds ok to you, my suggestion is to close/wontfix this.

You are receiving this mail because:
You are on the CC list for the bug.

More information about the Gdb-prs mailing list