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

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>

Over one year passed now,  did anybody made any progress regarding this
issue?

On 9 February 2017 at 16:33, Gaetano Checinski <gaetano.checinski at
gmail.com>
wrote:
> 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.
>>
>
>

-- 
Regards,

Gaetano Checinski
Founder of Loopperfect
https://loopperfect.com
https://buckaroo.pm
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
<http://lists.llvm.org/pipermail/llvm-dev/attachments/20180422/12730341/attachment.html>