llvm dev - Jul 2015 - [LLVMdev] Adding a stack probe function attribute

On Tue, Jul 28, 2015 at 2:25 AM, John Kåre Alsaker <
john.mailinglists at gmail.com> wrote:
> On Tue, Jul 28, 2015 at 12:44 AM, Reid Kleckner <rnk at google.com>
wrote:
> > Yeah, the function attributes section of LangRef is a reasonable place
to
> > put stuff like this:
> > http://llvm.org/docs/LangRef.html#function-attributes
> I'll see if I can't sneak something in there.
>
> >
> > I think we should add this. I also know that LLILAC needs something
like
> > this as well. I propose the following:
> > - Add a string attribute called
"stack-probe-symbol"="foo".
> > - The presence of this attribute indicates that stack probes should be
> > emitted, even on non-Windows OSs.
> > - (future work) For LLILAC, if this attribute is present but the
string
> is
> > empty, this can be a signal that the check must be emitted inline,
> either as
> > a sequence of stores or a loop.
> >
> > This also addresses David's concern with the hardcoded
__probestack
> symbol
> > name.
> First of all, LLVM should be free to choose how it does stack probes,
> it could call ___chkstk_ms, ___chkstk_ms, __chkstk, _alloca, _chkstk,
> __probestack or any other stack probe function it knows about, it
> could unroll and inline it for smaller allocation amounts, it could
> inline the function entirely or it could do nothing, for platforms
> which does stack overflow checks in hardware.
>
> I don't see why hardcoding __probestack is different from every other
> hardcoded thing in LLVM. Furthermore since calls to it can be elided
> it is not useful for clients to specify their own function, so they
> would just point it to whatever the platform stack probing function
> would be (replicating the ugly logic in
> X86FrameLowering::emitStackProbeCall). If LLVM in the future always
> inlined the call, the stack probe function would never be called and
> the attribute argument is useless.
>
The difference between __probestack and __chkstk etc is that we are happy
to call into existing interfaces that are somehow guaranteed by the
environment. Sometimes we do invent our own in compiler-rt for obscure
cases like i128 division, but it's rare. After years of adapting to fit
pre-existing interfaces, we are naturally very cautious to define our own.
Since not everyone uses compiler-rt, I worry about a situation where people
fight over the definition of __probestack, or where users want to override
__probestack to call into their runtime, rather than dealing with signals.
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20150728/28733a9b/attachment.html>

On Tue, Jul 28, 2015 at 6:34 PM, Reid Kleckner <rnk at google.com>
wrote:
> On Tue, Jul 28, 2015 at 2:25 AM, John Kåre Alsaker
> <john.mailinglists at gmail.com> wrote:
>>
>> On Tue, Jul 28, 2015 at 12:44 AM, Reid Kleckner <rnk at
google.com> wrote:
>> > Yeah, the function attributes section of LangRef is a reasonable
place
>> > to
>> > put stuff like this:
>> > http://llvm.org/docs/LangRef.html#function-attributes
>> I'll see if I can't sneak something in there.
>>
>> >
>> > I think we should add this. I also know that LLILAC needs
something like
>> > this as well. I propose the following:
>> > - Add a string attribute called
"stack-probe-symbol"="foo".
>> > - The presence of this attribute indicates that stack probes
should be
>> > emitted, even on non-Windows OSs.
>> > - (future work) For LLILAC, if this attribute is present but the
string
>> > is
>> > empty, this can be a signal that the check must be emitted inline,
>> > either as
>> > a sequence of stores or a loop.
>> >
>> > This also addresses David's concern with the hardcoded
__probestack
>> > symbol
>> > name.
>> First of all, LLVM should be free to choose how it does stack probes,
>> it could call ___chkstk_ms, ___chkstk_ms, __chkstk, _alloca, _chkstk,
>> __probestack or any other stack probe function it knows about, it
>> could unroll and inline it for smaller allocation amounts, it could
>> inline the function entirely or it could do nothing, for platforms
>> which does stack overflow checks in hardware.
>>
>> I don't see why hardcoding __probestack is different from every
other
>> hardcoded thing in LLVM. Furthermore since calls to it can be elided
>> it is not useful for clients to specify their own function, so they
>> would just point it to whatever the platform stack probing function
>> would be (replicating the ugly logic in
>> X86FrameLowering::emitStackProbeCall). If LLVM in the future always
>> inlined the call, the stack probe function would never be called and
>> the attribute argument is useless.
>
>
> The difference between __probestack and __chkstk etc is that we are happy
to
> call into existing interfaces that are somehow guaranteed by the
> environment. Sometimes we do invent our own in compiler-rt for obscure
cases
> like i128 division, but it's rare. After years of adapting to fit
> pre-existing interfaces, we are naturally very cautious to define our own.
The code does need to go somewhere though.
> Since not everyone uses compiler-rt, I worry about a situation where people
> fight over the definition of __probestack
Wouldn't this be resolved by defining what __probestack does?
> , or where users want to override
> __probestack to call into their runtime, rather than dealing with signals.
As I said before, calls to __probestack are not guaranteed to be
emitted, so clients can't rely on it doing anything other than probing
the stack. Also clients must always deal with guard page faults. Those
will usually happen outside of __probestack, since functions with
large stack frames are rare.

Rust is going ahead and removing it's abuse of segmented stack support
for stack overflow checking
(https://github.com/rust-lang/rust/pull/27338). This leaves it without
foolproof stack overflow checking. So it would be nice if this could
land soonish.

I suggest the following:

Add a "probe-stack" attribute (which can become a proper attribute
named probestack later), leaving the implementation of stack probing
up to LLVM.

Implement stack probing for x86 on non-Windows platforms with a call
to __probestack, with __probestack being added to compiler-rt.

Implement stack probing for ARM using the same code as Windows only
with __chkstk renamed to __probestack.

Other backends should use __probestack as the name for the stack
probing function if needed.

If there turns out to be an issue with the stack probe function name,
add a "stack-probe-function" attribute later (which goes along with
"stack-probe-size") allowing users to use their own name for the stack
probe function.