[PATCH] Prologue support

Reid Kleckner rnk at google.com
Mon Dec 1 11:46:53 PST 2014


On Mon, Dec 1, 2014 at 11:29 AM, Peter Collingbourne <peter at pcc.me.uk>
wrote:

> On Fri, Nov 28, 2014 at 09:36:27PM -0500, Stephen Checkoway wrote:
> >
> > On Nov 28, 2014, at 10:20 AM, Ben Gamari <bgamari at gmail.com> wrote:
> >
> > > Here we redefine the notion of prefix data to instead be data which
> > > occurs immediately before the function entrypoint (i.e. the symbol
> > > address). Since prefix data now occurs before the function entrypoint,
> > > there is no need for the data to be valid code.
> >
> > I seem to recall that when prefix data was being discussed previously,
> it came up that putting data before the symbol wouldn't work for OS X
> because of .subsections_via_symbols (or maybe some other reason). Peter may
> remember the details better.
>
> Oh yes, I remember this; I think .subsections_via_symbols was the problem.
> I think if we wanted this to work on OS X we would need to store the
> metadata
> as prologue data, and teach the frontend to take an offset from the
> function
> pointer. This might need a change in IR semantics to say that calling a
> (constant) offseted function pointer does the same thing as calling the
> function directly.
>

I'd rather not make that semantic change. Optimizers want to see direct
calls, and funky constant offsets will break that.

It seems to me that we can actually handle this at the MC layer instead. MC
would emit the symbol prior to the prefix data, and would rewrite all
relocations against the symbol as relocations with an addend. Then again,
maybe MachO relocations aren't powerful enough to express that. =P

It would also require TUs that lack the function definition to know how big
the prefix data is. Basically, the prefix data would have to be present on
the declaration as well as the definition. Do we support that for prologue
data currently?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20141201/4645e1fc/attachment.html>


More information about the llvm-commits mailing list