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

Eric Christopher via llvm-dev llvm-dev at lists.llvm.org
Fri Feb 19 18:39:31 PST 2016


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/20160220/b4676dbb/attachment-0001.html>


More information about the llvm-dev mailing list