User account creation filtered due to spam.
Reading specs from c:/programs/WinAVR/bin/../lib/gcc/avr/3.4.1/specs
Configured with: ../gcc-3.4.1/configure --prefix=e:/avrdev/install
--build=mingw32 --host=mingw32 --target=avr --enable-languages=c,c++
Thread model: single
gcc version 3.4.1
avr-gcc -gdwarf-2 bitfieldbug.c -o bf.elf
The debug output as shown by avr-readelf -w bf.elf shows that the first bitfield
member has a DW_AT_data_member_location of ff ff ff ff ff, which is obviously
This behaviour seems to persist no matter how I define the bitfield.
int main(int arcg, char **argv)
bf.j = 3;
This has been discussed on the gcc mailinglist:
From the link in comment #1, on the gcc list, from Jim Wilson:
"> DW_AT_member_location seems to consequently equal -1 (ff ff ff ff) for the > first member of a bitfield.
FYI You can get descriptive assembly by using the -dA option. This adds comments that make the dwarf2 debug info readable. Gcc calls this DW_AT_data_member_location.
The DWARF2 info comes from dwarf2out.c. Grepping for DW_AT_data_member_location shows that it comes from the function add_data_member_location_attribute. The offset comes from the function field_byte_offset. Looking at this code, it seems to have a general problem on targets where TYPE_ALIGN of int is smaller than TYPE_SIZE of int. This is true on avr where the size is 2 but the alignment is 1. The code computes the end of the bitfield, subtracts the type size, and then rounds up to the alignment, which gives -1 for the offset, which is not a useful number. I would think the code would work better if we started with the beginning of the bitfield, and then rounded down to the alignment. I'd suggest checking the history of the code to see if there is a reason why it was written this way. There may be an obscure reason why the code is like it is."
The issue is in field_byte_offset() in dwarf2out.c.
Can someone with Bugzilla permissions please mark this bug as NEW (confirmed)?
Bug fixed in 4.3.0 20070817 snapshot.