target hooks for structure layout

[Zack Weinberg]

DJ Delorie <dj@redhat.com> writes:

> I propose that three hooks be added for target-specific structure
> layout, providing access to three levels of detail to optimize the
> amount of work the target maintainer needs to do.
>
> 1. layout_structure()
>
> 	Called once per struct or union type, the target does all the
> 	work for laying out the structure.  The default hook will
> 	contain the code from layout_type()'s RECORD/UNION/QUAL_UNION
> 	case, with such code modified to call the next hook.
>
> 2. layout_structure_field()
>
> 	Called once per field.  The default hook will effectively be
> 	place_field, modified to call the next hook.
>
> 3. layout_structure_bitfield()
>
> 	Called once per bitfield.  This will be called from
> 	place_field for bitfields.  The default hook will be one of a
> 	few functions which handle the pcc/non-pcc/ms cases.
>
> Note that the APIs for these needs to be such that the target can
> optionally chain to one of the default handlers for common cases that
> it need not handle, thus reducing code duplication.  For example, a
> target might call the PCC bitfield layout function, but tweak the
> alignment for certain types of fields first, or pad some types in some
> cases.
>
>
> So, does this seem like an appropriate set of hooks for structure
> layout?
>
>
> The case I was trying to work on which was rejected was Renesas ABI
> structures, where bitfields are always allocated LSB first, NOT
> low-address first.  For this case, I'd need to hook the first and
> third case above; the first so I can tweak the offsets after the
> structure is laid out and the third would chain to either the usual
> hook (GCC mode) or the MS-compatible hook (Renesas mode).

These sound plausible, but could you be more specific about how they
interact?  I am confused by your example - it sounds like, if you
defined the first hook, nothing would ever call the second or third...

zw