[LLVMdev] Adding a stack probe function attribute

[Philip Reames]

Thanks for the explanation.  I'm used to hearing the term "stack 
banging" used for this mechanism, but I understand your objective.

I believe having a general mechanism here would be valuable, but only if 
the implementation doesn't make assumptions about runtime environment.  
For example, let's say my runtime uses a three page guard region and 
considers anything in that region to be a stack expansion.  This should 
work with your attribute.

There's also different ways of implementing this.  Depending on your 
runtime, you might want to a) call a function, b) emit some special 
loads.  There's also numerous optimizations which apply for the later 
implementation choice.

Worth noting is that stack banging only when the stack size is larger 
than a page size is NOT sufficient unless you can *prove* that every 
smaller frame actually reads or writes to the frame before calling a 
subroutine.

As an example, consider the following recursive function:
int test(int i) { char buff[50]; if( i == 0 ) return 0; else return 
test(i-1); }

The arguments will be passed in registers.  The buffer won't be 
initialized (assuming it's not compiled away), and you'll push a stack 
frame without touching the stack memory.


It would be nice if your attribute could also represent an explicit 
conditional check implementation as well.


Also, are you expecting the runtime to be able to throw an exception at 
the site of the check?  If so, there's a bunch of other issues which 
need handled.


Straw man ideas:
- Start with an string attribute, work out the semantics and 
implementation, then propose a "real attribute" once we've settled on a 
workable implementation.
- Pick a more generic name.  Possibly "StackOverflowGuard"?
- Use two parameters.  First, "minimum guard region size" (non-negative 
integer number of bytes).  Second, "test mechanism" (enum (FuncCall, 
Load, Store, ConditionalCheck)).  For the conditional check version, 
you'd need a way to specify a failure handler.    For the func call 
version, you need a way to set the routine.


Now, I realize this is well beyond what you originally wanted to 
implement.  If you wanted to make the minimum change you could to 
support forcing the enable of the existing stack probe mechanism, we can 
discuss specifically that.  I'd lean away from a general attribute for 
that purpose, but am open to being convinced otherwise.  :)

Philip


On 07/31/2014 07:27 PM, John Kåre Alsaker wrote:
> The point of this is to cheaply detect all stack overflows using a 
> guard page. For a guard page to actually detect all stack overflows, 
> we need to ensure that the code touches each page of the stack in the 
> right order, otherwise it could skip the guard page and write outside 
> the stack. That is very bad for languages such as Rust which provides 
> memory safety, so it currently does an explicit comparison against the 
> end of the stack for each function, which is again bad for 
> performance. This would correspond to GCC's -fstack-check (if that 
> worked).
>
>
> On Thu, Jul 31, 2014 at 6:40 PM, Philip Reames 
> <listmail at philipreames.com <mailto:listmail at philipreames.com>> wrote:
>
>     Giving a bit of background and motivation would be good here.  
>     What are you trying to accomplish and why?
>
>     Philip
>
>
>     On 07/28/2014 04:16 PM, John Kåre Alsaker wrote:
>>     Hi, I want to add a stack probe function attribute which would
>>     insert stack probes on all platforms, not just Windows. This will
>>     be useful for Rust since it must guarantee that the stack can't
>>     overflow, which it currently abuses the segmented stack support
>>     for. I'm not sure which kind of attribute is appropriate here. It
>>     must be added to the caller when inlined and clients of LLVM
>>     should be able to tell if code generation supports it. I would
>>     like some tips on how to implement this.
>>
>>
>>     _______________________________________________
>>     LLVM Developers mailing list
>>     LLVMdev at cs.uiuc.edu  <mailto:LLVMdev at cs.uiuc.edu>          http://llvm.cs.uiuc.edu
>>     http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev
>
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20140801/17717fb6/attachment.html>