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. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20140729/7691e07c/attachment.html>
Here's an implementation of this: http://reviews.llvm.org/D4717 There's no way to tell if stack probes actually are being generated though... On Tue, Jul 29, 2014 at 1:16 AM, John Kåre Alsaker < john.mailinglists at gmail.com> 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. >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20140731/2748fb5b/attachment.html>
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 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/20140731/3a1cd152/attachment.html>
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> 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 listLLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.eduhttp://lists.cs.uiuc.edu/mailman/listinfo/llvmdev > > >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20140801/1314294d/attachment.html>