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

Mon Feb 22 17:00:22 PST 2016

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>