<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Mon, Dec 1, 2014 at 11:29 AM, Peter Collingbourne <span dir="ltr"><<a href="mailto:peter@pcc.me.uk" target="_blank">peter@pcc.me.uk</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">On Fri, Nov 28, 2014 at 09:36:27PM -0500, Stephen Checkoway wrote:<br>
><br>
> On Nov 28, 2014, at 10:20 AM, Ben Gamari <<a href="mailto:bgamari@gmail.com">bgamari@gmail.com</a>> wrote:<br>
><br>
> > Here we redefine the notion of prefix data to instead be data which<br>
> > occurs immediately before the function entrypoint (i.e. the symbol<br>
> > address). Since prefix data now occurs before the function entrypoint,<br>
> > there is no need for the data to be valid code.<br>
><br>
> 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.<br>
<br>
</div></div>Oh yes, I remember this; I think .subsections_via_symbols was the problem.<br>
I think if we wanted this to work on OS X we would need to store the metadata<br>
as prologue data, and teach the frontend to take an offset from the function<br>
pointer. This might need a change in IR semantics to say that calling a<br>
(constant) offseted function pointer does the same thing as calling the<br>
function directly.<br></blockquote><div><br></div><div>I'd rather not make that semantic change. Optimizers want to see direct calls, and funky constant offsets will break that.</div><div><br></div><div>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</div><div><br></div><div>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?</div></div></div></div>