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

Gaetano Checinski via cfe-dev cfe-dev at lists.llvm.org
Tue Feb 7 07:53:22 PST 2017


Thanks for your quick answer.

> It's a missing feature/bug in the x86 backend
did anyone try to implement an IR-transformer to emulate thread_local ?

> JIT dynamic loader an't cope with the relocations that get generated.
how difficult would it be to fix this ?


2017-02-07 15:35 GMT+00:00 Tim Northover <t.p.northover at gmail.com>:

> On 6 February 2017 at 03:49, Gaetano Checinski via cfe-dev
> <cfe-dev at lists.llvm.org> wrote:
> > LLVM ERROR: Cannot select: 0xd012e0:
> >      i64 = X86ISD::WrapperRIP TargetGlobalTLSAddress:i64<i8**
> @_ZSt15__once_callable> 0 [TF=10]
> >
> >  0xd020c0: i64 = TargetGlobalTLSAddress<i8** @_ZSt15__once_callable> 0
> [TF=10]
> > In function: _ZSt9call_onceIMNSt13__future_base13_State_
> baseV2EFvPSt8functionIFSt10unique_ptrINS0_12_Result_baseENS4_8_
> DeleterEEvEEPbEJPS1_S9_SA_EEvRSt9once_flagOT_DpOT0_
> >
> > Questions:
> >
> > What does it mean?
>
> 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".
>
> That's a compilation mode where the assembly is emitted that can run
> from anywhere in memory. During normal compilation "small" is used,
> the compiler assumes code will end up in the low 2GB of memory, and
> the linker makes sure this is true.
>
> Unfortunately when JITing, you can't usually guarantee that the OS
> will give you memory in the low 2GB so the default is "large", which
> is obviously less robust since it's less commonly used.
>
> > Are there any compiler-flags that fix this problem?
>
> Unfortunately it doesn't seem so. Using "lli -relocation-model=pic"
> gets around the immediate problem but then the JIT dynamic loader
> can't cope with the relocations that get generated.
> > what specific features is libstdc++ using that cause this issue ?
>
> Any thread-local storage would do it.
>
> > How does my problem relate to Bug 21431?
>
> Looks like exactly the same issue.
>
> Cheers.
>
> Tim.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20170207/0f650953/attachment.html>


More information about the cfe-dev mailing list