[Bug rust/22936] New: some tests fail with rustc 1.24

[tromey at sourceware dot org]

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

Bug ID: 22936
Summary: some tests fail with rustc 1.24
Product: gdb
Version: HEAD
Status: NEW
Severity: normal
Priority: P2
Component: rust
Assignee: unassigned at sourceware dot org
Reporter: tromey at sourceware dot org
Target Milestone: ---

rustc 1.24 causes some test failures in simple.exp and generics.exp.

For simple.exp the problem so far seems to be that the debuginfo changed.
Now rustc emits this for a rust enum member:

<3><2c99>: Abbrev Number: 18 (DW_TAG_member)
<2c9a> DW_AT_type : <0x2cc8>
<2c9e> DW_AT_byte_size : 24
<2c9f> DW_AT_bit_size : 8
<2ca0> DW_AT_bit_offset : 56
<2ca1> DW_AT_data_member_location: 0x1ffffffffffffff0


Maybe the bit and byte sizes disagree because the data doesn't occupy the
full width? DWARF seems to specify this behavior for base types but
that's the only rationale I could come up with.

Also the data member location seems incorrect.

[tromey at sourceware dot org]

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

Tom Tromey <tromey at sourceware dot org> changed:

What |Removed |Added
----------------------------------------------------------------------------
Assignee|unassigned at sourceware dot org |tromey at sourceware dot org

[tromey at sourceware dot org]

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

--- Comment #1 from Tom Tromey <tromey at sourceware dot org> ---
DWARF 5.7.6 Data Member Entries:

The member entry corresponding to a data member that is defined in a structure,
union or class may have either a DW_AT_data_member_location attribute or a
DW_AT_data_bit_offset attribute.

...and

If the size of a data member is not the same as the size of the type given for
the
data member, the data member has either a DW_AT_byte_size or a
DW_AT_bit_size attribute whose integer constant value (see Section 2.19 on
page 55) is the amount of storage needed to hold the value of the data member.


My reading of these is that the bit and byte sizes are exclusive.
Contrast with the language for base types:

If the value of an object of the given type does not fully occupy the storage
described by a byte size attribute, the base type entry may also have a
DW_AT_bit_size and a DW_AT_data_bit_offset attribute, both of whose values
are integer constant values (see Section 2.19 on page 55). The bit size
attribute
describes the actual size in bits used to represent values of the given type.
The
data bit offset attribute is the offset in bits from the beginning of the
containing
storage to the beginning of the value. Bits that are part of the offset are
padding.

[mark at klomp dot org]

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

Mark Wielaard <mark at klomp dot org> changed:

What |Removed |Added
----------------------------------------------------------------------------
CC| |mark at klomp dot org

--- Comment #2 from Mark Wielaard <mark at klomp dot org> ---
Do you have the full DIE tree for this structure and enum type?
Also could you show how the values are encoded (eu-readelf should tell you).
Or could you attach a minimal reproducer?

I agree that a DW_TAG_member cannot both have a DW_AT_byte_size and
DW_AT_bit_size, that doesn't really make sense.

Did you reach out to the rustc compiler people to ask why they encode things
this way and what they believe the interpretation is?

[tromey at sourceware dot org]

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

--- Comment #3 from Tom Tromey <tromey at sourceware dot org> ---
(In reply to Mark Wielaard from comment #2)

Post by mark at klomp dot org
Do you have the full DIE tree for this structure and enum type?
Also could you show how the values are encoded (eu-readelf should tell you).
Or could you attach a minimal reproducer?

If you install rustc 1.24 a pretty small test case is already in gdb.
I'll append the eu-readelf dump of the relevant DWARF.

Post by mark at klomp dot org
Did you reach out to the rustc compiler people to ask why they encode things
this way and what they believe the interpretation is?

Not yet, but I'll do that.


The enum "MoreComplicated" from simple.rs looks like:

pub struct HiBob {
pub field1: i32,
field2: u64,
}

enum MoreComplicated {
One,
Two(i32),
Three(HiBob),
Four{this: bool, is: u8, a: char, struct_: u64, variant: u32},
}


I left out "HiBob" and also the type of the discriminant from this DWARF:


[ 2c92] union_type
name (strp) "MoreComplicated"
byte_size (data1) 24
??? (0x88) (udata) 8
[ 2c99] member
type (ref4) [ 2cc8]
byte_size (data1) 24
bit_size (data1) 8
bit_offset (data1) 56
data_member_location (data8) 1ffffffffffffff0
[ 2ca9] member
type (ref4) [ 2cdb]
byte_size (data1) 24
bit_size (data1) 64
bit_offset (data1) 0
data_member_location (data8) 1ffffffffffffff0
[ 2cb9] member
type (ref4) [ 2cf9]
??? (0x88) (udata) 8
data_member_location (data1) 0
[ 2cc0] member
type (ref4) [ 2d35]
??? (0x88) (udata) 8
data_member_location (data1) 0
[ 2cc8] structure_type
name (strp) "One"
byte_size (data1) 24
??? (0x88) (udata) 8
[ 2ccf] member
name (strp) "RUST$ENUM$DISR"
type (ref4) [ 2750]
??? (0x88) (udata) 1
data_member_location (data1) 0
[ 2cdb] structure_type
name (strp) "Two"
byte_size (data1) 24
??? (0x88) (udata) 8
[ 2ce2] member
name (strp) "RUST$ENUM$DISR"
type (ref4) [ 2750]
??? (0x88) (udata) 1
data_member_location (data1) 0
[ 2ced] member
name (strp) "__0"
type (ref4) [ 3056]
??? (0x88) (udata) 4
data_member_location (data1) 4
[ 2cf9] structure_type
name (strp) "Three"
byte_size (data1) 24
??? (0x88) (udata) 8
[ 2d00] member
name (strp) "RUST$ENUM$DISR"
type (ref4) [ 2750]
??? (0x88) (udata) 1
data_member_location (data1) 0
[ 2d0b] member
name (strp) "__0"
type (ref4) [ 2d17]
??? (0x88) (udata) 8
data_member_location (data1) 8
[ 2d17] structure_type
name (strp) "HiBob"
byte_size (data1) 16
??? (0x88) (udata) 8
[ 2d1e] member
name (strp) "field1"
type (ref4) [ 3056]
??? (0x88) (udata) 4
data_member_location (data1) 8
[ 2d29] member
name (strp) "field2"
type (ref4) [ 3081]
??? (0x88) (udata) 8
data_member_location (data1) 0
[ 2d35] structure_type
name (strp) "Four"
byte_size (data1) 24
??? (0x88) (udata) 8
[ 2d3c] member
name (strp) "RUST$ENUM$DISR"
type (ref4) [ 2750]
??? (0x88) (udata) 1
data_member_location (data1) 0
[ 2d47] member
name (strp) "this"
type (ref4) [ 3088]
??? (0x88) (udata) 1
data_member_location (data1) 1
[ 2d52] member
name (strp) "is"
type (ref4) [ 2e40]
??? (0x88) (udata) 1
data_member_location (data1) 2
[ 2d5d] member
name (strp) "a"
type (ref4) [ 308f]
??? (0x88) (udata) 4
data_member_location (data1) 4
[ 2d68] member
name (strp) "struct_"
type (ref4) [ 3081]
??? (0x88) (udata) 8
data_member_location (data1) 10
[ 2d73] member
name (strp) "variant"
type (ref4) [ 3096]
??? (0x88) (udata) 4
data_member_location (data1) 8

[tromey at sourceware dot org]

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

--- Comment #4 from Tom Tromey <tromey at sourceware dot org> ---
I was misreading the base type text of course; I think there's just
no support for having both attributes.

LLVM is doing this:

bool IsBitfield = FieldSize && Size != FieldSize;
if (IsBitfield) {
// Handle bitfield, assume bytes are 8 bits.
if (DD->useDWARF2Bitfields())
addUInt(MemberDie, dwarf::DW_AT_byte_size, None, FieldSize/8);
addUInt(MemberDie, dwarf::DW_AT_bit_size, None, Size);

See
https://github.com/llvm-mirror/llvm/blob/master/lib/CodeGen/AsmPrinter/DwarfUnit.cpp#L1505-L1510

[tromey at sourceware dot org]

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

--- Comment #5 from Tom Tromey <tromey at sourceware dot org> ---
Maybe this line
(https://github.com/llvm-mirror/llvm/blob/master/lib/CodeGen/AsmPrinter/DwarfUnit.cpp#L1533):

OffsetInBytes = FieldOffset >> 3;

explains the weird value for DW_AT_data_member_location

[tromey at sourceware dot org]

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

--- Comment #6 from Tom Tromey <tromey at sourceware dot org> ---
... the idea being, FieldOffset is unsigned, so if it underflows
then the resulting calculation is wrong.

[tromey at sourceware dot org]

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

--- Comment #7 from Tom Tromey <tromey at sourceware dot org> ---
These weird results can be explained by running the LLVM algorithm
with Size=8 (bits) and FieldSize=192 (aka 24 bytes).
Since the alignment code assumes the field size is a power of 2,
things go awry.

[tromey at sourceware dot org]

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

--- Comment #8 from Tom Tromey <tromey at sourceware dot org> ---
Filed as https://bugs.llvm.org/show_bug.cgi?id=36654

I'm not sure exactly which approach I want to take to fixing this yet;
choices being (1) minimal llvm fix, (2) land by bigger patch
for https://github.com/rust-lang/rust/issues/32920 (which would keep
lldb broken for the time being), (3) work around it in gdb, (4) or
maybe some combination of the above.

[tromey at sourceware dot org]

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

Tom Tromey <tromey at sourceware dot org> changed:

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

--- Comment #9 from Tom Tromey <tromey at sourceware dot org> ---
Rust enum debug info was improved here:
https://github.com/rust-lang/rust/pull/54004
So I think this is fixed now.