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

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>

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>

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

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>