llvm dev - Apr 2016 - RFC: New function attribute "patchable-prologue"="<kind>"

Thanks for looping me in Eric!

If I was going to suggest anything here, I'd like to think about a more
general approach than a very specific attribute like this. My preference is
something like "patchable-function"="kind,kind,..." (if
that's even
possible). This allows us to have common infrastructure for being able to
implement different kinds of function-level patching routines at the same
time or even just generalising this mechanism with the instrumentation
attribute(s).

It would help probably if I'm able to say more, potentially in the form of
an RFC for what Eric and I are working on. :D

Cheers

On Thu, Apr 14, 2016 at 6:13 AM Eric Christopher <echristo at gmail.com>
wrote:
> On Thu, Apr 7, 2016 at 4:35 PM Sanjoy Das <sanjoy at
playingwithpointers.com>
> wrote:
>
>> Hi Eric,
>>
>> Eric Christopher wrote:
>>  > Two things:
>>  >
>>  > a) I'm not against this
>>
>> Great!
>>
>>  > b) So, what's your use case? I've got something I'm
idly working on
>> with
>>  > someone else where we want patchable targets in both prologue and
>>  > epilogue (and some other places...), and am thinking of how to
make
>> this
>>  > someone generic enough to build off of there.
>>
>> We plan to use this to be able to divert control flow from an LLVM
>> compiled function to "somewhere else" where the
"somewhere else" is
>> usually a differently optimized version of the same function.  One
>>
>>
> Right. So, I've got a use case that I'm working on over here that
uses,
> basically, patchable prologue and epilogue and am hoping that this ends up
> being general enough for both.
>
> I'll take a look at the patch since you've sent it out, but would
really
> like to not have to change a lot of how it works. :)
>
> -eric
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20160414/9b2d8631/attachment.html>

Hi Dean, Eric,

Dean Michael Berris wrote:
 > If I was going to suggest anything here, I'd like to think about a
more
 > general approach than a very specific attribute like this. My preference
 > is something like "patchable-function"="kind,kind,..."
(if that's even
 > possible). This allows us to have common infrastructure for being able
 > to implement different kinds of function-level patching routines at the
 > same time or even just generalising this mechanism with the
 > instrumentation attribute(s).

I've updated D19046 to use "patchable-function", can one of you
please
take a look?

Thanks,
-- Sanjoy

On Thu, Apr 14, 2016 at 6:45 AM Dean Michael Berris <dberris at
google.com>
wrote:
> Thanks for looping me in Eric!
>
>
:)

> If I was going to suggest anything here, I'd like to think about a more
> general approach than a very specific attribute like this. My preference is
> something like "patchable-function"="kind,kind,..." (if
that's even
> possible). This allows us to have common infrastructure for being able to
> implement different kinds of function-level patching routines at the same
> time or even just generalising this mechanism with the instrumentation
> attribute(s).
>
> It would help probably if I'm able to say more, potentially in the form
of
> an RFC for what Eric and I are working on. :D
>
>
Yeah, we're almost there right? Sanjoy is jumping the gun on us a bit :)

patchable-function is a fairly terrible name, but an enum list of valid
kinds seems to work for me. We might end up having to make it an exclusive
list rather than a combined list due to people wanting different size
patchable areas.

-eric


> Cheers
>
> On Thu, Apr 14, 2016 at 6:13 AM Eric Christopher <echristo at
gmail.com>
> wrote:
>
>> On Thu, Apr 7, 2016 at 4:35 PM Sanjoy Das <sanjoy at
playingwithpointers.com>
>> wrote:
>>
>>> Hi Eric,
>>>
>>> Eric Christopher wrote:
>>>  > Two things:
>>>  >
>>>  > a) I'm not against this
>>>
>>> Great!
>>>
>>>  > b) So, what's your use case? I've got something
I'm idly working on
>>> with
>>>  > someone else where we want patchable targets in both prologue
and
>>>  > epilogue (and some other places...), and am thinking of how
to make
>>> this
>>>  > someone generic enough to build off of there.
>>>
>>> We plan to use this to be able to divert control flow from an LLVM
>>> compiled function to "somewhere else" where the
"somewhere else" is
>>> usually a differently optimized version of the same function.  One
>>>
>>>
>> Right. So, I've got a use case that I'm working on over here
that uses,
>> basically, patchable prologue and epilogue and am hoping that this ends
up
>> being general enough for both.
>>
>> I'll take a look at the patch since you've sent it out, but
would really
>> like to not have to change a lot of how it works. :)
>>
>> -eric
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20160414/bb48bcbb/attachment.html>

I think most function redirection patching schemes are going to be mutually
incompatible, so I'm not sure it makes sense to make this attribute a
comma-separated list.

I think Eric's and Dean's use case may be better addressed by a separate
attribute. My recollection is that they want to add nop slides to the
prologue and epilogue that can be hotpatched to enable and disable
instrumentation at runtime.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20160414/a061e542/attachment.html>