Re: representation of struct field offsets

[Mark Mitchell <mark at codesourcery dot com>]

Sandra Loosemore wrote:

> I've been having a heck of a time figuring out how to translate the 
> offsets for struct fields from the DWARF encoding back to GCC's internal 
> encoding for the LTO project.

Yes, that's a nasty bit.

I think the DECL_FIELD_OFFSET/DECL_FIELD_BIT_OFFSET stuff is, quite 
simply, mis-designed.  The way I think it should work is for 
DECL_FIELD_OFFSET to be the byte offset, and DECL_FIELD_BIT_OFFSET to be 
the bit offset, always less than BITS_PER_UNIT.  But, that's not how it 
actually works.  Instead, the BIT_OFFSET is kept below the alignment of 
the field, rather than BITS_PER_UNIT.

The bit of dwarf2out.c that emits the offset for the field is 
add_data_member_location_attribute.  It uses 
dwarf2out.c:field_byte_offset, which is the function that normalizes the 
weird GCC representation into the obvious one.  I don't know why it's 
using a custom function; I would think it should just use 
tree.c:byte_position.  The current DWARF code looks oddly heuristic.

But that doesn't explain why you're not getting idempotent results.  Are 
you going through the stor_layout.c:place_field routines when creating 
structure types?  If so, I wouldn't; here, you know where stuff is 
supposed to go, so I would just put it there, and set DECL_FIELD_OFFSET, 
etc., accordingly.

My bet is that you are not setting DECL_ALIGN, or that we have failed to 
set TYPE_ALIGN somewhere, and that, therefore, the heuristics in 
dwarf2out.c:field_byte_offset are getting confused.  For example, 
simple_type_align_in_bits might not be working.  I would probably step 
through field_byte_offset both when compiling C and in LTO mode, and try 
to see where it goes different.

It shouldn't be necessary as part of this work, but I can't see why we 
should just replace field_byte_offset with a use of byte_position.  Does 
anyone else know?

--
Mark Mitchell
CodeSourcery
mark@codesourcery.com
(650) 331-3385 x713