Re: avr-gcc, .debug_frame and bitfields

[Jim Wilson <wilson at specifixinc dot com>]

Torleif Sandnes wrote:
> Why does not gcc produce an .debug_frame section for the avr target?

The debug_frame sections are very target dependent, and require writing 
some target dependent support.  If you just want enough for gdb to work, 
then it is probably a small amount of work.  If you want enough for 
efficient C++ EH to work, then it is probably a moderate amount of work.

See
  http://gcc.gnu.org/ml/gcc/2004-03/msg01779.html
for a nice description of how the EH stuff works.  The first part of 
this covers the eh_frame (aka debug_frame) section.

> 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.
--
Jim Wilson, GNU Tools Support, http://www.SpecifixInc.com