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

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>

On Tue, Feb 23, 2016 at 04:47:32AM +0000, Tim Shen
wrote:
> 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.
(4) Create an intrinisinc for the SSP cookie itself and allow targets to use
different lowering passed on factors like the OS.

Joerg

On Tue, Feb 23, 2016 at 4:47 AM Joerg Sonnenberger via llvm-dev <
llvm-dev at lists.llvm.org> wrote:
> On Tue, Feb 23, 2016 at 04:47:32AM +0000, Tim Shen wrote:
> > 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.
>
> (4) Create an intrinisinc for the SSP cookie itself and allow targets to
> use
> different lowering passed on factors like the OS.
>
Yeah I think this is better. Thanks!

So suppose we have a intrinsic ssp_cookie, when SelectionDAG visits it, it
calls target specific function getSspCookie(...):
    virtual SDNode getSspCookie(...) const;

Compared to returning a Value* to a function pass
(lib/CodeGen/StackProtector.cpp), returning a SDNode requires less wrapping
on backend (e.g. Intrinsic::aarch64_thread_pointer).
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20160224/9c3cfe99/attachment.html>