25.09.2009 20:51, Roland McGrath wrote:
> $ src/dwarfcmp ./a.out ./a.out.out
> 3d vs 57: data_member_location={locexpr} vs
> data_member_location={loclist 1 entries}
>
> It's certainly not optimal to store it this way, but aren't these two
> cases actually equal? (Um, assuming there's no other difference, like
> the bytecode being actually different, which I didn't check.)
Technically it's not even possible to have a location list in
DW_AT_data_member_location, unless you're using the new DW_FORM_sec_offset.
(Any data* form there is not a loclistptr, but a constant.)
Hmm, per the spec, DW_AT_data_member_location can be of class block,
constant, or loclistptr. I emit it as DW_FORM_data8 (data4 would have
sufficed for 32-bit Dwarf, but that's another story), with the intended
semantic of `loclistptr'. And that's how our tools understand it.
I think in the current code a plain location expr should be treated
the
same as a location list with a single range from 0 to ~0. It might not
be smart about ~0 in 32-bit address-size though, that wouldn't surprise me.
What's the actual dump of these two objects?
./a.out, relevant part of .debug_info:
[ 3d] inheritance
type [ 2d]
data_member_location 2 byte block: 23 00
[ 0] plus_uconst 0
./a.out.out, head of .debug_loc:
DWARF section [33] '.debug_loc' at offset 0x15b3:
[ 0] 000000000000000000..0xffffffffffffffff [ 0] plus_uconst 0
Hex dump of section [33] '.debug_loc', 220 bytes at offset 0x15b3:
0x00000000 00000000 00000000 ffffffff ffffffff ................
0x00000010 02002300 00000000 00000000 00000000 ..#.............
(0x02, 0x00 will be two bytes of length of bytecode block, and the
bytecode block then 0x23, 0x00, which matches the original file.)
PM