Re: representation of struct field offsets

[Dale Johannesen <dalej at apple dot com>]

On Sep 27, 2006, at 7:04 PM, 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.  I've got a handle on the  
> DWARF encoding and how to do the necessary big/little endian  
> conversions, but for the GCC side, there doesn't seem to be any  
> documentation about the relevant macros in the manual, and the  
> comments in tree.h don't seem to reflect what is actually going on  
> in the representation.
>
> For example, DECL_FIELD_OFFSET is supposed to be "the field  
> position, counting in bytes, of the byte containing the bit closest  
> to the beginning of the structure", while DECL_FIELD_BIT_OFFSET is  
> supposed to be "the offset, in bits, of the first bit of the field  
> from DECL_FIELD_OFFSET".  So I'm quite puzzled why, for fields that  
> are not bit fields and that are aligned on byte boundaries, the C  
> front end is generating a DECL_FIELD_OFFSET that points to some  
> byte that doesn't contain any part of the field, and a non-zero  
> DECL_FIELD_BIT_OFFSET instead.  If I make the LTO front end do what  
> the comments in tree.h describe, then dwarf2out.c produces  
> incorrect offsets that don't match those from the original C file.
>
> I see in stor-layout.c that there are routines to "perform  
> computations that convert between the offset/bitpos forms and byte  
> and bit offsets", but what exactly are these forms and which values  
> are the ones that I should actually be storing inside the  
> FIELD_DECL object?  Is it possible to compute the DECL_OFFSET_ALIGN  
> value somehow, given that it's not encoded in the DWARF  
> representation?  Trying to reverse-engineer dwarf2out.c isn't  
> turning out to be very productive....  :-P

I had to look at this recently and I wound up looking at it this  
way.  The total bit offset is represented as
(byte offset) + (8* bit offset);
there are multiple ways to do that that produce the same result, and  
gcc's choice of which one it uses
is, as you say, somewhat arbitrary.  However all the different ways  
seem to work equivalently for
codegen purposes.  I'm not familiar with the dwarf representation,  
but the same information must be
there, so perhaps the dwarf code could impose a canonical form if  
necessary.