[Dwarf-Discuss] DWARF2 - Endianity issues for DW_AT_bit_offsetfields
Anitha.Boyapati at atmel.com
Fri Sep 16 05:30:28 PDT 2011
(Sorry for the delay. I was traveling)
>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
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