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 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. On Sun, Jul 26, 2015 at 2:23 AM, John Kåre Alsaker < john.mailinglists at gmail.com> wrote:> Since David Majnemer doesn't seem overly eager to merge my patches, > let's see if we can't figure things out here. > > I noticed a string function attribute appeared in LangRef.rst, would > that be the correct place to document this? > > For reference: > http://reviews.llvm.org/D9653 > http://reviews.llvm.org/D9654 > http://reviews.llvm.org/D9858 > > On Wed, Aug 6, 2014 at 5:34 PM, John Kåre Alsaker > <john.mailinglists at gmail.com> wrote: > > I updated http://reviews.llvm.org/D4717 and also wrote an __probestack > > implementation: > > https://github.com/Zoxc/compiler-rt/compare/llvm-mirror:master...stprobe > > > > Which instruction would be the preferable one to probe with? I used OR > since > > that's what GCC/libgcc does, but I don't see why that would be better > than a > > write. > > > > > > > > On Tue, Aug 5, 2014 at 7:34 PM, Reid Kleckner <rnk at google.com> wrote: > >> > >> On Tue, Aug 5, 2014 at 8:53 AM, John Kåre Alsaker > >> <john.mailinglists at gmail.com> wrote: > >>> > >>> Would the __probestack functions be a suitable addition to compiler-rt? > >>> Does it already have __chkstk or is that provided by something else on > >>> Windows? I noticed that libgcc implemented them in cygwin.S. > >> > >> > >> It seems reasonable to put them in compiler-rt/lib/builtins. > >> > >> I don't think anyone is currently using compiler-rt's builtins on > Windows, > >> so it doesn't have __chkstk. Typically that is provided by the Cygwin, > >> MinGW, or MSVC C runtime. > > > > >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20150727/d5265097/attachment.html>
For what it's worth, I need stack probes as well. My language usecase has two relevant properties: 1. The language guarantees total memory safety/sandboxing. Malicious programs are unable to negatively affect the rest of the system beyond consuming resources. 2. The user of the language is allowed significant expressive power, letting him manipulate the stack. Stack probes prevent users of a language from skipping over the guard page; it's the last memory hole to be plugged once the rest of the system is secure. I think in general, any language that has these two properties will require either stack probes or a much more complicated system (like geordi, segmented stacks, or obsessive loading of allocated memory). A great number of languages fall into this situation. On Mon, Jul 27, 2015 at 3:44 PM, 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 > <https://urldefense.proofpoint.com/v2/url?u=http-3A__llvm.org_docs_LangRef.html-23function-2Dattributes&d=AwMFaQ&c=8hUWFZcy2Z-Za5rBPlktOQ&r=Mfk2qtn1LTDThVkh6-oGglNfMADXfJdty4_bhmuhMHA&m=9SIQM2l9LBT0fy7gjw3gZ_JGUTA7MIRtzMSZmlqBtHI&s=R92M4dbBo9gOD8RfWBKDtYxbDkJFmKDuX_aVP3Wx5IE&e=> > > 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. > > On Sun, Jul 26, 2015 at 2:23 AM, John Kåre Alsaker < > john.mailinglists at gmail.com> wrote: > >> Since David Majnemer doesn't seem overly eager to merge my patches, >> let's see if we can't figure things out here. >> >> I noticed a string function attribute appeared in LangRef.rst, would >> that be the correct place to document this? >> >> For reference: >> http://reviews.llvm.org/D9653 >> <https://urldefense.proofpoint.com/v2/url?u=http-3A__reviews.llvm.org_D9653&d=AwMFaQ&c=8hUWFZcy2Z-Za5rBPlktOQ&r=Mfk2qtn1LTDThVkh6-oGglNfMADXfJdty4_bhmuhMHA&m=9SIQM2l9LBT0fy7gjw3gZ_JGUTA7MIRtzMSZmlqBtHI&s=gV_4pNmG2FALSPJQnNAjqjGyIRfdizkPb8iOmuKtSf8&e=> >> http://reviews.llvm.org/D9654 >> <https://urldefense.proofpoint.com/v2/url?u=http-3A__reviews.llvm.org_D9654&d=AwMFaQ&c=8hUWFZcy2Z-Za5rBPlktOQ&r=Mfk2qtn1LTDThVkh6-oGglNfMADXfJdty4_bhmuhMHA&m=9SIQM2l9LBT0fy7gjw3gZ_JGUTA7MIRtzMSZmlqBtHI&s=FWQzb_lQwqWGOu9ERJCGtouQpV0sCATZiW3nESlX4hU&e=> >> http://reviews.llvm.org/D9858 >> <https://urldefense.proofpoint.com/v2/url?u=http-3A__reviews.llvm.org_D9858&d=AwMFaQ&c=8hUWFZcy2Z-Za5rBPlktOQ&r=Mfk2qtn1LTDThVkh6-oGglNfMADXfJdty4_bhmuhMHA&m=9SIQM2l9LBT0fy7gjw3gZ_JGUTA7MIRtzMSZmlqBtHI&s=ceno8V9VFeBJBroOdwCco5sUIbSxH9vlZQoPnkGe9b8&e=> >> >> On Wed, Aug 6, 2014 at 5:34 PM, John Kåre Alsaker >> <john.mailinglists at gmail.com> wrote: >> > I updated http://reviews.llvm.org/D4717 >> <https://urldefense.proofpoint.com/v2/url?u=http-3A__reviews.llvm.org_D4717&d=AwMFaQ&c=8hUWFZcy2Z-Za5rBPlktOQ&r=Mfk2qtn1LTDThVkh6-oGglNfMADXfJdty4_bhmuhMHA&m=9SIQM2l9LBT0fy7gjw3gZ_JGUTA7MIRtzMSZmlqBtHI&s=ibz-wRihBgpHNnNZPBdBfNEk9rzM_RKH_9aputdPTYA&e=> >> and also wrote an __probestack >> > implementation: >> > >> https://github.com/Zoxc/compiler-rt/compare/llvm-mirror:master...stprobe >> <https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_Zoxc_compiler-2Drt_compare_llvm-2Dmirror-3Amaster...stprobe&d=AwMFaQ&c=8hUWFZcy2Z-Za5rBPlktOQ&r=Mfk2qtn1LTDThVkh6-oGglNfMADXfJdty4_bhmuhMHA&m=9SIQM2l9LBT0fy7gjw3gZ_JGUTA7MIRtzMSZmlqBtHI&s=EzU7LhO9y-f1kS1q6Yr76NSnyLRtOQ7LJeFru3G9wDU&e=> >> > >> > Which instruction would be the preferable one to probe with? I used OR >> since >> > that's what GCC/libgcc does, but I don't see why that would be better >> than a >> > write. >> > >> > >> > >> > On Tue, Aug 5, 2014 at 7:34 PM, Reid Kleckner <rnk at google.com> wrote: >> >> >> >> On Tue, Aug 5, 2014 at 8:53 AM, John Kåre Alsaker >> >> <john.mailinglists at gmail.com> wrote: >> >>> >> >>> Would the __probestack functions be a suitable addition to >> compiler-rt? >> >>> Does it already have __chkstk or is that provided by something else on >> >>> Windows? I noticed that libgcc implemented them in cygwin.S. >> >> >> >> >> >> It seems reasonable to put them in compiler-rt/lib/builtins. >> >> >> >> I don't think anyone is currently using compiler-rt's builtins on >> Windows, >> >> so it doesn't have __chkstk. Typically that is provided by the Cygwin, >> >> MinGW, or MSVC C runtime. >> > >> > >> > > > _______________________________________________ > 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/20150727/daa894fa/attachment.html>
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-attributesI'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. -> > On Sun, Jul 26, 2015 at 2:23 AM, John Kåre Alsaker > <john.mailinglists at gmail.com> wrote: >> >> Since David Majnemer doesn't seem overly eager to merge my patches, >> let's see if we can't figure things out here. >> >> I noticed a string function attribute appeared in LangRef.rst, would >> that be the correct place to document this? >> >> For reference: >> http://reviews.llvm.org/D9653 >> http://reviews.llvm.org/D9654 >> http://reviews.llvm.org/D9858 >> >> On Wed, Aug 6, 2014 at 5:34 PM, John Kåre Alsaker >> <john.mailinglists at gmail.com> wrote: >> > I updated http://reviews.llvm.org/D4717 and also wrote an __probestack >> > implementation: >> > https://github.com/Zoxc/compiler-rt/compare/llvm-mirror:master...stprobe >> > >> > Which instruction would be the preferable one to probe with? I used OR >> > since >> > that's what GCC/libgcc does, but I don't see why that would be better >> > than a >> > write. >> > >> > >> > >> > On Tue, Aug 5, 2014 at 7:34 PM, Reid Kleckner <rnk at google.com> wrote: >> >> >> >> On Tue, Aug 5, 2014 at 8:53 AM, John Kåre Alsaker >> >> <john.mailinglists at gmail.com> wrote: >> >>> >> >>> Would the __probestack functions be a suitable addition to >> >>> compiler-rt? >> >>> Does it already have __chkstk or is that provided by something else on >> >>> Windows? I noticed that libgcc implemented them in cygwin.S. >> >> >> >> >> >> It seems reasonable to put them in compiler-rt/lib/builtins. >> >> >> >> I don't think anyone is currently using compiler-rt's builtins on >> >> Windows, >> >> so it doesn't have __chkstk. Typically that is provided by the Cygwin, >> >> MinGW, or MSVC C runtime. >> > >> > > >
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>