Re: locexpr vs. loclist 1 entry

[Petr Machata <pmachata at redhat dot com>]

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