llvm dev - Jan 2016 - [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>

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>

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>

----- 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>

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

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>