[Dwarf-Discuss] DWARF2 - Endianity issues for DW_AT_bit_offset fields

[David Earlam]

Anitha, 

I checked two other little-endian 32-bit, octet-addressing C compilers, one producing Dwarf2, one producing Dwarf3.

They both agree with the gcc you used on little-endian x86.

<2><b3>: Abbrev Number: 37 (DW_TAG_member)
   <b4>   DW_AT_name        : l
   <b6>   DW_AT_type        : DW_FORM_ref1 <0x61> "unsigned char"
   <b8>   DW_AT_data_member_location: 2 byte block: 23 1                         (DW_OP_plus_uconst: 1)
   <bb>   DW_AT_byte_size   : 1
   <bc>   DW_AT_bit_size    : 2
   <bd>   DW_AT_bit_offset  : 6


When the bitfield 'l' would have straddled two storage units, the compiler chose to start a new storage unit (C structure packing is implementation- defined). Updates to 'l' then only need access one byte at addr+1 with a mask 0x03.

If the bitfield straddled two bytes, generated code would usually need to access two bytes, shift the first left 1, shift the second right 7, bitwise-or together and maybe mask with 0x03 to form the field into a unsigned char value (or a similar sequence leastwise on a processor without deposit/extract instructions). 

So with that debug_info, the struct test surely looks like this:

 39    32 31    24 23    16 15     8 7      0
 +--------+--------+--------+--------+--------+
 | addr+4 | addr+3 | addr+2 | addr+1 | addr+0 |
 +--------+--------+--------+--------+--------+
  .................................Ll pKkkkkBA

where p is padding.

That might not be the case for __packed structures, if the compiler has this non-standard extension, which avoid such padding and pack as closely as possible.

According to Dwarf 2.0.0 section 5.5.4 Structure Data Member Entries,
the DW_AT_data_member_location is the address relative to the composite object that most closely encloses the bitfield; so if 'l' straddled that relative address could be DW_OP_plus_uconst 0 or DW_OP_plus_uconst 1, but the DW_AT_bit_offset is always from the MSB of the anonymous addressed object containing the field, so it can be disambiguated, but it is awkward, hence Dwarf v4's new DW_AT_data_bit_offset.


Also, don't rely on DW_AT_byte_size being there. It is optional and you then have to use the size of the container type.

David




Member of the CSR plc group of companies. CSR plc registered in England and Wales, registered number 4187346, registered office Churchill House, Cambridge Business Park, Cowley Road, Cambridge, CB4 0WZ, United Kingdom
More information can be found at www.csr.com. Follow CSR on Twitter at http://twitter.com/CSR_PLC and read our blog at www.csr.com/blog