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

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/20160211/2b273409/attachment-0001.html>

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>