[llvm-dev] [PPC] Linker fails on -fstack-protector

[Tim Shen via llvm-dev]

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>