[Dwarf-Discuss] DWARF2 - Endianity issues for DW_AT_bit_offsetfields

[Boyapati, Anitha]

Hello David,

Thanks for the explanation.

There is one more little-endian architecture - AVR on which I work. I get this output for 'l' of test. (gcc 4.5.1)

<2><5e>: Abbrev Number: 4 (DW_TAG_member)
    <5f>   DW_AT_name        : l
    <61>   DW_AT_decl_file   : 1
    <62>   DW_AT_decl_line   : 6
    <63>   DW_AT_type        : <0x75>
    <67>   DW_AT_byte_size   : 1
    <68>   DW_AT_bit_size    : 2
    <69>   DW_AT_bit_offset  : 0xffffffff 0xffffffff
    <71>   DW_AT_data_member_location: 2 byte block: 23 0       (DW_OP_plus_uconst: 0)


>From the output I think the layout is as follows:

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

However it assumes a container type of char which 1 byte aligned on 0 byte (same as that of the structure) and uses -ve offset to indicate that MSB of l extends beyond the container type. Hence -1 for DW_AT_bit_offset.

As DWARF2/3 spec, does not say anything about DW_AT_bit_offset being unsigned, I am presuming that the above output is equally correct. Is it not?

Anitha

>-----Original Message-----
>From: David Earlam [mailto:David.Earlam at csr.com]
>Sent: Wednesday, September 07, 2011 9:06 PM
>To: Boyapati, Anitha; DWARF discussion mailing list
>Subject: RE: [Dwarf-Discuss] DWARF2 - Endianity issues for
>DW_AT_bit_offsetfields
>
>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