Tim Shen via llvm-dev
2016-Jan-25 19:57 UTC
[llvm-dev] [PPC] Linker fails on -fstack-protector
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. 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? Thanks! -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160125/a7e9306f/attachment.html>
Kyle Butt via llvm-dev
2016-Jan-28 01:11 UTC
[llvm-dev] [PPC] Linker fails on -fstack-protector
On Mon, Jan 25, 2016 at 11:57 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. > > 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. > >Can you try to implement the intrinsic for x86 as a proof of concept?> Details are in the bug: https://llvm.org/bugs/show_bug.cgi?id=26226 > > Any ideas? > > Thanks! > > _______________________________________________ > LLVM Developers mailing list > llvm-dev at lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev > >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160127/231f8b62/attachment.html>
Eric Christopher via llvm-dev
2016-Feb-11 00:59 UTC
[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. > > 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 >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160211/59e113bf/attachment.html>
Hal Finkel via llvm-dev
2016-Feb-11 01:04 UTC
[llvm-dev] [PPC] Linker fails on -fstack-protector
----- Original Message -----> 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? -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/20160210/ec7417f1/attachment.html>
Joerg Sonnenberger via llvm-dev
2016-Feb-22 23:32 UTC
[llvm-dev] [PPC] Linker fails on -fstack-protector
On Mon, Jan 25, 2016 at 07:57:43PM +0000, Tim Shen via llvm-dev wrote:> 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.It would also be inefficient on architectures that can directly access TLS variables. I.e. on x86, it is effectively a statically allocated TLS variable with fixed offset. That can be accessed by a single load -- whereas introducing get_tcb_address first would require a second load. Joerg
Tim Shen via llvm-dev
2016-Feb-23 00:26 UTC
[llvm-dev] [PPC] Linker fails on -fstack-protector
On Mon, Feb 22, 2016 at 3:32 PM Joerg Sonnenberger via llvm-dev < llvm-dev at lists.llvm.org> wrote:> On Mon, Jan 25, 2016 at 07:57:43PM +0000, Tim Shen via llvm-dev wrote: > > 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. > > It would also be inefficient on architectures that can directly access > TLS variables. I.e. on x86, it is effectively a statically allocated TLS > variable with fixed offset. That can be accessed by a single load -- > whereas introducing get_tcb_address first would require a second load.Guess I used the wrong intrinsic name - it should be llvm.global_tls_address(), and it should be directly lowered to ISD::GlobalTLSAddress, which is currently used by both x86 and ppc, and ultimately it's referencing fs register on x86_64 and r13 on ppc64le. -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160223/6fb9314a/attachment.html>