<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Fri, Aug 1, 2014 at 11:12 PM, Philip Reames <span dir="ltr"><<a href="mailto:listmail@philipreames.com" target="_blank">listmail@philipreames.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000">
Thanks for the explanation. I'm used to hearing the term "stack
banging" used for this mechanism, but I understand your objective.
<br>
<br>
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. <br>
<br>
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.</div></blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div bgcolor="#FFFFFF" text="#000000">
<br>
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. <br>
<br>
As an example, consider the following recursive function:<br>
int test(int i) { char buff[50]; if( i == 0 ) return 0; else return
test(i-1); }<br>
<br>
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. <br></div></blockquote><div>I don't think that will happen unless there's a separate call stack. Either the call instruction itself will write to the stack or it will be tail recursive call and the stack will be reused.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div bgcolor="#FFFFFF" text="#000000">
<br>
<br>
It would be nice if your attribute could also represent an explicit
conditional check implementation as well. <br></div></blockquote><div>The "split-stack" attribute can be used for that, and that's what Rust currently does.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000">
<br>
<br>
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. <br>
<br>
<br>
Straw man ideas:<br>
- Start with an string attribute, work out the semantics and
implementation, then propose a "real attribute" once we've settled
on a workable implementation. <br></div></blockquote><div>I seemed to have read that string attributes were for platform specific things, would that be incorrect?</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000">
- Pick a more generic name. Possibly "StackOverflowGuard"?<br>
- 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. <br>
<br>
<br>
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. :)</div></blockquote><div>I think this should be limited to only lightweight stack probing, which either emits probe instructions or calls a function (provided by libgcc/compiler-rt) which does exactly the same. One extension I'm open for is to always force a probe which ensures the stack overflow happens in a well defined point in the prologue. That could be used for languages which can recover from stack overflows.</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div bgcolor="#FFFFFF" text="#000000"><span class="HOEnZb"><font color="#888888"><br>
<br>
Philip</font></span><div><div class="h5"><br>
<br>
<br>
<div>On 07/31/2014 07:27 PM, John Kåre
Alsaker wrote:<br>
</div>
<blockquote type="cite">
<div dir="ltr">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).</div>
<div class="gmail_extra"><br>
<br>
<div class="gmail_quote">On Thu, Jul 31, 2014 at 6:40 PM, Philip
Reames <span dir="ltr"><<a href="mailto:listmail@philipreames.com" target="_blank">listmail@philipreames.com</a>></span>
wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div bgcolor="#FFFFFF" text="#000000"> Giving a bit of
background and motivation would be good here. What are
you trying to accomplish and why?<br>
<br>
Philip
<div><br>
<br>
<div>On 07/28/2014 04:16 PM, John Kåre Alsaker wrote:<br>
</div>
</div>
<blockquote type="cite">
<div>
<div dir="ltr">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.</div>
<br>
<fieldset></fieldset>
<br>
</div>
<pre>_______________________________________________
LLVM Developers mailing list
<a href="mailto:LLVMdev@cs.uiuc.edu" target="_blank">LLVMdev@cs.uiuc.edu</a> <a href="http://llvm.cs.uiuc.edu" target="_blank">http://llvm.cs.uiuc.edu</a>
<a href="http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev" target="_blank">http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev</a>
</pre>
</blockquote>
<br>
</div>
</blockquote>
</div>
<br>
</div>
</blockquote>
<br>
</div></div></div>
</blockquote></div><br></div></div>