[Dwarf-Discuss] DWARF2 - Endianity issues for DW_AT_bit_offsetfields

Boyapati, Anitha Anitha.Boyapati@atmel.com
Fri Sep 16 12:30:28 GMT 2011

(Sorry for the delay. I was traveling)

>Hi Anitha,
>Yes, it's valid.
>If I use gcc 4.4.4 (x86 mingw tdm) with '-g -fpack-struct' arguments
>firstly, the compiler reports
>  dwarfbits.c:6: note: Offset of packed bit-field 'l' has changed in GCC
>  - since an earlier gcc version I guess -
>then secondly, 'objdump -W' of the produced Dwarf2 also says
><2><80>: Abbrev Number: 4 (DW_TAG_member)
>    <81>   DW_AT_name        : l
>    <83>   DW_AT_decl_file   : 1
>    <84>   DW_AT_decl_line   : 5
>    <85>   DW_AT_type        : <0x93>
>    <89>   DW_AT_byte_size   : 1
>    <8a>   DW_AT_bit_size    : 2
>    <8b>   DW_AT_bit_offset  : 0xffffffff
>    <8f>   DW_AT_data_member_location: 2 byte block: 23 0
>	(DW_OP_plus_uconst: 0)
>The debug_abbrev for DW_AT_bit_offset is DW_FORM_data4, I assume it is
>DW_FORM_data8 for you. (I didn't actually know AVR's could address that
>much memory, or just maybe there's a problem around here in GCC4.5.3 or the
>AVR port.)

This is a bug with gcc. (http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47946)

The information is not configured in AVR. So I guess whatever is the default behavior of GCC, it should be reflected.

>It'd be easier to understand if the compiler were to use DW_FORM_sdata for
>'signed constant' class of DW_AT_bit_offset then it is clearly signed for
>the DWARF consumer.
>However if you interpret that DW_AT_bit_offset value as signed the 2 bit-
>field 'l' straddles addr+1 and addr+0. It all makes sense.



More information about the Dwarf-discuss mailing list