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

[Gaetano Checinski via llvm-dev]

I'm looking currently into a patch
<https://mailtrack.io/trace/link/60b02baa5e1b3d7ffe6fbb428b343be17c58c583?url=https%3A%2F%2Fgithub.com%2FJuliaLang%2Fllvm%2Fcommit%2Fa9e17b7f47f5afa9683fc8cfeff7020b2ff4a8b2%23diff-0fa8ca8690e36a8dfd05f6b751955164R339&signature=222c65b9d92c011f>
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>