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

[Tim Shen via llvm-dev]

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>