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

[Gaetano Checinski via llvm-dev]

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>