This is the mail archive of the
mailing list for the GCC project.
Re: target hooks for structure layout
- From: Zack Weinberg <zack at codesourcery dot com>
- To: DJ Delorie <dj at redhat dot com>
- Cc: gcc at gcc dot gnu dot org
- Date: Mon, 21 Jun 2004 13:53:49 -0700
- Subject: Re: target hooks for structure layout
- References: <200406212033.i5LKXFlM028428@greed.delorie.com>
DJ Delorie <firstname.lastname@example.org> 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
> So, does this seem like an appropriate set of hooks for structure
> 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...