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

Tim Shen via llvm-dev llvm-dev at lists.llvm.org
Tue Feb 23 16:06:44 PST 2016


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>


More information about the llvm-dev mailing list