[PATCH] Prologue support

[Peter Collingbourne]

On Mon, Dec 01, 2014 at 11:46:53AM -0800, Reid Kleckner wrote:
> 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

This makes a lot more sense (provided that the relocations work out).

> 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?

Yes, to a certain extent. It is specified that prologue data on declarations
works like available_externally, but I never got around to implementing any
of that.

This prompted me to reread my earlier mail on this subject in which I mentioned
the idea of having the prefix type separate from its "initializer" [1],
and another mail in which I proposed "symbol offsets" [2], and in general
refresh my memory on this subject.

I don't think we would need to do rewriting at the MC layer; we can handle
this purely in codegen. I've attached an old patch I was working on at one
point that made a start on implementing the symbol offset feature. What
we need here is basically the reverse of this idea, where the object file
symbol appears before the IR symbol.

It might be simplest to say that only the type of the prefix data on a
declaration is significant (i.e. drop the specified available_externally
semantics). Then a frontend can simply create an undef of the appropriate
type to specify how big the prefix data is.

Thanks,
-- 
Peter

[1] http://lists.cs.uiuc.edu/pipermail/llvmdev/2014-May/073262.html
[2] http://lists.cs.uiuc.edu/pipermail/llvmdev/2013-April/061511.html
-------------- next part --------------
A non-text attachment was scrubbed...
Name: symboloffset.diff
Type: text/x-diff
Size: 13683 bytes
Desc: not available
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20141201/90203b61/attachment.diff>