Tim Shen via llvm-dev
2016-Feb-20 02:38 UTC
[llvm-dev] [PPC] Linker fails on -fstack-protector
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/20160220/43ed5715/attachment.html>
Eric Christopher via llvm-dev
2016-Feb-20 02:39 UTC
[llvm-dev] [PPC] Linker fails on -fstack-protector
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/20160220/b4676dbb/attachment-0001.html>
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>