[llvm-dev] [cfe-dev] lli: LLVM ERROR: Cannot select: X86ISD::WrapperRIP TargetGlobalTLSAddress:i64

Gaetano Checinski via llvm-dev llvm-dev at lists.llvm.org
Thu Feb 9 08:33:26 PST 2017

I'm looking currently into a patch
which has been written for JuliaLang and is supposed to fix TLS for linux.
Unfortunately it is based on llvm3.6 and uses RuntimeDyLdELF::findGOTEntry.
Is there any equivalent method in llvm4.0 ?

2017-02-08 19:40 GMT+00:00 Tim Northover <t.p.northover at gmail.com>:

> [Adding llvm-dev back to list]
> On 8 February 2017 at 11:12, Gaetano Checinski
> <gaetano.checinski at gmail.com> wrote:
> > Thanks for sharing your insights,
> > so in theory i could build an llvm pass that calls TargetLowering::LowerToTLSEmulatedModel
> for each llvm::Function and it should work if i link a runtime that
> provides __emultls_get_address.
> I'm afraid not, that function is called as part of converting from a
> Function to a MachineFunction. It operates on a completely different
> representation to normal LLVM IR. The only way to trigger it is to set
> the right field in the TargetOptions.
> > >It's a missing feature/bug in the x86 backend. The specific problem is
> > >that it seems we don't support thread-local variables with what Clang
> > >& GCC would call "-mcmodel=large".
> >
> > Would it be a better approach to fix this issue ?
> Yes, I think that'd be the proper fix for the issue. It's possible the
> JIT parts don't support TLS at all yet either, which would mean we
> have to implement it there.
> > How difficult would it be ?
> I don't think there are any fundamental difficulties; the ABI already
> exists because GCC can cope. On the JIT side, it'll be a case of
> supporting some relocations (pretty simple) and getting the output
> object's thread-local sections registered with the system somehow
> (more difficult, I'm not sure what each platform's callbacks are).
> It's probably measured in days even for someone who knows many of the
> details already though.
> Cheers.
> Tim.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20170209/9267a6c7/attachment.html>

More information about the llvm-dev mailing list