Tim Shen via llvm-dev
2016-Feb-22 23:23 UTC
[llvm-dev] [PPC] Linker fails on -fstack-protector
I found a bit weird to use address space for this, since the offset of getting stack_guard in TCB is, unfortunately, negative: https://github.com/gcc-mirror/gcc/blob/master/gcc/config/rs6000/linux64.h#L610 In my understanding an address space is referring to a segment register (-on powerpc 32bit; or SLB entry on powerpc 64bit?) with a non-negative offset value, so that it's actually accessing data in the specified segment. In our case, I feel accessing r13 (TCB pointer) is more different than I thought. I'm considering turning to add a target *independent* IR intrinsic "llvm.get_tcb_address()". It's target independent because glibc does this for several platforms, and we probably want to solve it once for all: ~/src/glibc % grep -r 'stack_guard;' . ./sysdeps/mach/hurd/i386/tls.h: uintptr_t stack_guard; ./sysdeps/i386/nptl/tls.h: uintptr_t stack_guard; ./sysdeps/sparc/nptl/tls.h: uintptr_t stack_guard; ./sysdeps/s390/nptl/tls.h: uintptr_t stack_guard; ./sysdeps/powerpc/nptl/tls.h: uintptr_t stack_guard; ./sysdeps/x86_64/nptl/tls.h: uintptr_t stack_guard; ./sysdeps/tile/nptl/tls.h: uintptr_t stack_guard; Opinions? On Fri, Feb 19, 2016 at 6:39 PM Eric Christopher <echristo at gmail.com> wrote:> Sounds good. > > Thanks! > > -eric > > On Fri, Feb 19, 2016 at 6:38 PM Tim Shen <timshen at google.com> wrote: > >> I'll come up with a address-space-based proof of concept. >> >> On Wed, Feb 10, 2016, 17:05 Eric Christopher <echristo at gmail.com> wrote: >> >>> On Wed, Feb 10, 2016 at 5:04 PM Hal Finkel <hfinkel at anl.gov> wrote: >>> >>>> >>>> ------------------------------ >>>> >>>> *From: *"Eric Christopher" <echristo at gmail.com> >>>> *To: *"Tim Shen" <timshen at google.com>, llvm-dev at lists.llvm.org, "Hal >>>> Finkel" <hfinkel at anl.gov>, "Kit Barton" <kbarton at ca.ibm.com> >>>> *Sent: *Wednesday, February 10, 2016 6:59:50 PM >>>> *Subject: *Re: [llvm-dev] [PPC] Linker fails on -fstack-protector >>>> >>>> >>>> >>>> >>>> >>>> On Mon, Jan 25, 2016 at 11:58 AM Tim Shen via llvm-dev < >>>> llvm-dev at lists.llvm.org> wrote: >>>> >>>>> When -fstack-protector is turned on, linker fails to find the symbol "__stack_chk_guard" >>>>> because at least for powerpc64le, glibc doesn't provide this symbol. >>>>> Instead, they put the stack guard into TCB. >>>>> >>>>> x86 fixed this issue by injecting a special address space (which is >>>>> later translated to TCB register access) and hard code the offset of >>>>> stack_guard, but I don't see a easy way to handle address spaces in ppc. >>>>> >>>> >>>> >>>> Why is handling address spaces in ppc any more difficult than doing so >>>> for x86? >>>> >>> >>> Shouldn't be at all, mostly just seems that a bunch of it hasn't been >>> set up yet. >>> >>> -eric >>> >>> >>>> >>>> -Hal >>>> >>>> >>>>> A cleaner solution could be adding an IR intrinsic >>>>> llvm.get_tcb_address() and hard code the offset of stack_guard member, >>>>> since they aren't supposed to change. >>>>> >>>>> Details are in the bug: https://llvm.org/bugs/show_bug.cgi?id=26226 >>>>> >>>>> Any ideas? >>>>> >>>>> >>>> Not a huge fan of a ppc specific intrinsic (which it should be, so >>>> llvm.ppc... if we go that route) to do this. I actually rather liked the >>>> cleanliness of the address space solution for x86. How much work would it >>>> be to do that? Alternately: Hal, Kit, what do you two think as far as the >>>> ppc backend? >>>> >>>> The other solution you mentioned - combining the slot load into the >>>> existing intrinsic might work, we'd just need to figure out how to >>>> autoupgrade everything into it which might be a bit more difficult than >>>> fixing the backends and dealing. Have you looked into how the autoupgrade >>>> would work? >>>> >>>> Thanks! >>>> >>>> -eric >>>> >>>> >>>>> Thanks! >>>>> _______________________________________________ >>>>> LLVM Developers mailing list >>>>> llvm-dev at lists.llvm.org >>>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >>>>> >>>> >>>> >>>> >>>> -- >>>> Hal Finkel >>>> Assistant Computational Scientist >>>> Leadership Computing Facility >>>> Argonne National Laboratory >>>> >>>-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160222/672213d1/attachment.html>
Eric Christopher via llvm-dev
2016-Feb-23 01:00 UTC
[llvm-dev] [PPC] Linker fails on -fstack-protector
On Mon, Feb 22, 2016 at 3:23 PM Tim Shen <timshen at google.com> wrote:> I found a bit weird to use address space for this, since the offset of > getting stack_guard in TCB is, unfortunately, negative: > > https://github.com/gcc-mirror/gcc/blob/master/gcc/config/rs6000/linux64.h#L610 > > In my understanding an address space is referring to a segment register > (-on powerpc 32bit; or SLB entry on powerpc 64bit?) with a non-negative > offset value, so that it's actually accessing data in the specified segment. > > In our case, I feel accessing r13 (TCB pointer) is more different than I > thought. I'm considering turning to add a target *independent* IR intrinsic > "llvm.get_tcb_address()". It's target independent because glibc does this > for several platforms, and we probably want to solve it once for all: > ~/src/glibc % grep -r 'stack_guard;' . > ./sysdeps/mach/hurd/i386/tls.h: uintptr_t stack_guard; > ./sysdeps/i386/nptl/tls.h: uintptr_t stack_guard; > ./sysdeps/sparc/nptl/tls.h: uintptr_t stack_guard; > ./sysdeps/s390/nptl/tls.h: uintptr_t stack_guard; > ./sysdeps/powerpc/nptl/tls.h: uintptr_t stack_guard; > ./sysdeps/x86_64/nptl/tls.h: uintptr_t stack_guard; > ./sysdeps/tile/nptl/tls.h: uintptr_t stack_guard; >Yeah, for most of the architectures listed there it's not particularly useful as they support direct access to TLS variables (as Joerg says later). That grep isn't representative of how the data is actually accessed. If the current address space way of specifying isn't doable on PPC then that's fine (or feels icky). That said, the basic idea of keeping around the way to access the TLS variable is pretty easy, we do some amount of this in TargetLowering::getStackCookieLocation, but we might just need to come up with a new interface there that returns the address of the stack local load rather than an offset from an address space. -eric> > Opinions? > > On Fri, Feb 19, 2016 at 6:39 PM Eric Christopher <echristo at gmail.com> > wrote: > >> Sounds good. >> >> Thanks! >> >> -eric >> >> On Fri, Feb 19, 2016 at 6:38 PM Tim Shen <timshen at google.com> wrote: >> >>> I'll come up with a address-space-based proof of concept. >>> >>> On Wed, Feb 10, 2016, 17:05 Eric Christopher <echristo at gmail.com> wrote: >>> >>>> On Wed, Feb 10, 2016 at 5:04 PM Hal Finkel <hfinkel at anl.gov> wrote: >>>> >>>>> >>>>> ------------------------------ >>>>> >>>>> *From: *"Eric Christopher" <echristo at gmail.com> >>>>> *To: *"Tim Shen" <timshen at google.com>, llvm-dev at lists.llvm.org, "Hal >>>>> Finkel" <hfinkel at anl.gov>, "Kit Barton" <kbarton at ca.ibm.com> >>>>> *Sent: *Wednesday, February 10, 2016 6:59:50 PM >>>>> *Subject: *Re: [llvm-dev] [PPC] Linker fails on -fstack-protector >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> On Mon, Jan 25, 2016 at 11:58 AM Tim Shen via llvm-dev < >>>>> llvm-dev at lists.llvm.org> wrote: >>>>> >>>>>> When -fstack-protector is turned on, linker fails to find the symbol "__stack_chk_guard" >>>>>> because at least for powerpc64le, glibc doesn't provide this symbol. >>>>>> Instead, they put the stack guard into TCB. >>>>>> >>>>>> x86 fixed this issue by injecting a special address space (which is >>>>>> later translated to TCB register access) and hard code the offset of >>>>>> stack_guard, but I don't see a easy way to handle address spaces in ppc. >>>>>> >>>>> >>>>> >>>>> Why is handling address spaces in ppc any more difficult than doing so >>>>> for x86? >>>>> >>>> >>>> Shouldn't be at all, mostly just seems that a bunch of it hasn't been >>>> set up yet. >>>> >>>> -eric >>>> >>>> >>>>> >>>>> -Hal >>>>> >>>>> >>>>>> A cleaner solution could be adding an IR intrinsic >>>>>> llvm.get_tcb_address() and hard code the offset of stack_guard member, >>>>>> since they aren't supposed to change. >>>>>> >>>>>> Details are in the bug: https://llvm.org/bugs/show_bug.cgi?id=26226 >>>>>> >>>>>> Any ideas? >>>>>> >>>>>> >>>>> Not a huge fan of a ppc specific intrinsic (which it should be, so >>>>> llvm.ppc... if we go that route) to do this. I actually rather liked the >>>>> cleanliness of the address space solution for x86. How much work would it >>>>> be to do that? Alternately: Hal, Kit, what do you two think as far as the >>>>> ppc backend? >>>>> >>>>> The other solution you mentioned - combining the slot load into the >>>>> existing intrinsic might work, we'd just need to figure out how to >>>>> autoupgrade everything into it which might be a bit more difficult than >>>>> fixing the backends and dealing. Have you looked into how the autoupgrade >>>>> would work? >>>>> >>>>> Thanks! >>>>> >>>>> -eric >>>>> >>>>> >>>>>> Thanks! >>>>>> _______________________________________________ >>>>>> LLVM Developers mailing list >>>>>> llvm-dev at lists.llvm.org >>>>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev >>>>>> >>>>> >>>>> >>>>> >>>>> -- >>>>> Hal Finkel >>>>> Assistant Computational Scientist >>>>> Leadership Computing Facility >>>>> Argonne National Laboratory >>>>> >>>>-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160223/5471283a/attachment.html>
Tim Shen via llvm-dev
2016-Feb-23 04:47 UTC
[llvm-dev] [PPC] Linker fails on -fstack-protector
On Mon, Feb 22, 2016 at 5:00 PM Eric Christopher <echristo at gmail.com> wrote:> Yeah, for most of the architectures listed there it's not particularly > useful as they support direct access to TLS variables (as Joerg says > later). That grep isn't representative of how the data is actually > accessed. If the current address space way of specifying isn't doable on > PPC then that's fine (or feels icky). >It is certainly doable, but I feel icky: 1) It needs to support negative offset, which is weird when we are talking about address spaces; 2) Handling TLS is totally different from handling real ppc segments (which I assume address space is designed for); 3) TLS has a different semantic from address space ( http://llvm.org/docs/CodeGenerator.html#x86-address-spaces-supported).> That said, the basic idea of keeping around the way to access the TLS > variable is pretty easy, we do some amount of this in > TargetLowering::getStackCookieLocation, but we might just need to come up > with a new interface there that returns the address of the stack local load > rather than an offset from an address space. >I also found a similar case - getSafeStackPointerLocation(). On X86 it's implemented in terms of address space (similar to getStackCooikeLocation), but on AArch64 it's implemented in terms of a target specific AArch64ISD::THREAD_POINTER and Intrinsic::aarch64_thread_pointer. To make the fix least surprising, I can either do: 1) Create PPCISD::THREAD_POINTER and Intrinsic::ppc_thread_pointer and do similar things aarch64 does; or 2) Don't create PPCISD::THREAD_POINTER, but directly calls llvm.read_register intrinsic in ppc's getStackCookieLocation(). This is the way that requires least change; or 3) Create a generic ISD::GET_GLOBAL_TLS_ADDRESS and intrinsic llvm.get_global_tls_address(), and lower them to target specific ISD. No target specific intrinsic is needed. I was wrong about ISD::GlobalTlsAddress, since it requires a GlobalValue object. I prefer 3), since it's less hacky than 2) and less repetitive than 1). -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160223/4d642a28/attachment.html>
Kit Barton via llvm-dev
2016-Feb-23 05:18 UTC
[llvm-dev] [PPC] Linker fails on -fstack-protector
<div class="socmaildefaultfont" dir="ltr" style="font-family:Arial;font-size:10.5pt" ><div dir="ltr" ><span style="font-size:0.857em;" >Hi Tim,</span></div> <div dir="ltr" ><span style="font-size:0.857em;" >I'm a little confused about what you're trying to accomplish here.</span></div> <div dir="ltr" ><span style="font-size:0.857em;" >Are you trying to find a way to access the stack_guard in the TCB provided by glibc? </span></div> <div dir="ltr" ><span style="font-size:0.857em;" >If not, can we not just come up with our own definition of __stack_chk_guard and discuss the best way to implement that (perhaps not by putting it in the TCB)?</span></div> <div dir="ltr" > </div> <div dir="ltr" ><span style="font-size:0.857em;" >I'm not familiar with the GCC implementation, but I can talk to the GCC folks tomorrow to get some more details. I know that XL implemented this differently, but some specific details are a bit fuzzy. I'll refresh my memory on that tomorrow as well.</span></div> <div dir="ltr" > </div> <div dir="ltr" ><span style="font-size:0.857em;" >Thanks,</span></div> <div dir="ltr" > </div> <div dir="ltr" ><span style="font-size:0.857em;" >Kit Barton, Ph.D.<br>LLVM Development on POWER<br>IBM Toronto Lab, D2/929/8200/MKM<br>8200 Warden Ave, Markham, L6G 1C7<br>(905) 413-3452<br>kbarton@ca.ibm.com</span> <div> </div> <div> </div> <blockquote data-history-content-modified="1" style="border-left:solid #aaaaaa 2px; margin-left:5px; padding-left:5px; direction:ltr; margin-right:0px" >----- Original message -----<br>From: Tim Shen <timshen@google.com><br>To: Eric Christopher <echristo@gmail.com>, Hal Finkel <hfinkel@anl.gov>, Joerg Sonnenberger <joerg@britannica.bec.de><br>Cc: llvm-dev@lists.llvm.org, Kit Barton/Toronto/IBM@IBMCA, "kyle+llvm@iteratee.net" <kyle+llvm@iteratee.net><br>Subject: Re: [llvm-dev] [PPC] Linker fails on -fstack-protector<br>Date: Mon, Feb 22, 2016 11:47 PM<br> <div dir="ltr" ><div dir="ltr" ><div><div dir="ltr" >On Mon, Feb 22, 2016 at 5:00 PM Eric Christopher <<a href="mailto:echristo@gmail.com" target="_blank" >echristo@gmail.com</a>> wrote:</div> <blockquote style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex" ><div dir="ltr" ><div><div>Yeah, for most of the architectures listed there it's not particularly useful as they support direct access to TLS variables (as Joerg says later). That grep isn't representative of how the data is actually accessed. If the current address space way of specifying isn't doable on PPC then that's fine (or feels icky).</div></div></div></blockquote> <div> </div> <div>It is certainly doable, but I feel icky:</div> <div>1) It needs to support negative offset, which is weird when we are talking about address spaces;</div> <div>2) Handling TLS is totally different from handling real ppc segments (which I assume address space is designed for);</div> <div>3) TLS has a different semantic from address space (<a href="http://llvm.org/docs/CodeGenerator.html#x86-address-spaces-supported" target="_blank" >http://llvm.org/docs/CodeGenerator.html#x86-address-spaces-supported</a>).</div> <div> </div> <blockquote style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex" ><div dir="ltr" ><div><div>That said, the basic idea of keeping around the way to access the TLS variable is pretty easy, we do some amount of this in TargetLowering::getStackCookieLocation, but we might just need to come up with a new interface there that returns the address of the stack local load rather than an offset from an address space.</div></div></div></blockquote> <div> </div>I also found a similar case - getSafeStackPointerLocation(). On X86 it's implemented in terms of address space (similar to getStackCooikeLocation), but on AArch64 it's implemented in terms of a target specific AArch64ISD::THREAD_POINTER and Intrinsic::aarch64_thread_pointer.</div> <div><div> </div> <div>To make the fix least surprising, I can either do:</div> <div>1) Create PPCISD::THREAD_POINTER and Intrinsic::ppc_thread_pointer and do similar things aarch64 does; or</div> <div>2) Don't create PPCISD::THREAD_POINTER, but directly calls llvm.read_register intrinsic in ppc's getStackCookieLocation(). This is the way that requires least change; or</div> <div>3) Create a generic ISD::GET_GLOBAL_TLS_ADDRESS and intrinsic llvm.get_global_tls_address(), and lower them to target specific ISD. No target specific intrinsic is needed. I was wrong about ISD::GlobalTlsAddress, since it requires a GlobalValue object.</div> <div> </div> <div>I prefer 3), since it's less hacky than 2) and less repetitive than 1).</div></div></div></div></blockquote></div></div><BR>
Tim Shen via llvm-dev
2016-Feb-23 05:52 UTC
[llvm-dev] [PPC] Linker fails on -fstack-protector
On Mon, Feb 22, 2016 at 9:18 PM Kit Barton <kbarton at ca.ibm.com> wrote:> Hi Tim, > I'm a little confused about what you're trying to accomplish here. > Are you trying to find a way to access the stack_guard in the TCB provided > by glibc? >Yes.> If not, can we not just come up with our own definition of > __stack_chk_guard and discuss the best way to implement that (perhaps not > by putting it in the TCB)? > > I'm not familiar with the GCC implementation, but I can talk to the GCC > folks tomorrow to get some more details. I know that XL implemented this > differently, but some specific details are a bit fuzzy. I'll refresh my > memory on that tomorrow as well. >Based on my understanding, GCC simply hardcoded the register number and offset: https://github.com/gcc-mirror/gcc/blob/master/gcc/config/rs6000/linux64.h#L610, and I intend to do similar things here, except we may not need/want to hardcode register number. It'll be great if you and GCC folks can help. Thank you! -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160223/2ae8858b/attachment.html>