[llvm-dev] [RFC] lld: Dropping TLS relaxations in favor of TLSDESC

UE US via llvm-dev llvm-dev at lists.llvm.org
Thu Nov 9 10:53:41 PST 2017

I saw a very similar looking bug the other night, linker was trying to make
the TLS reloc 32 bit, things were setup for regular shared , and we got
ugly segfaults.   The best result I got in that case was -fPIE and
-model=medium (intel assembler undocumented, but it's not doing much
complicated.  The 32 bit TLS reloc changed to an X86_64_64 reloc... and
yes, it did appear to change it to a 64 bit reloc, probably designed for
situations like this.


On Thu, Nov 9, 2017 at 7:15 AM, Joerg Sonnenberger via llvm-dev <
llvm-dev at lists.llvm.org> wrote:

> On Wed, Nov 08, 2017 at 12:46:20PM -0800, Rui Ueyama via llvm-dev wrote:
> > So, looks like there are programs in where TLS relaxation actually
> matters.
> > It is interesting that both examples mentioned in this threads are
> > graphics-related (OpenGL and games). I wonder if it is a coincidence or
> it
> > is a common practice to use thread-local variables heavily in graphics. I
> > haven't wrote any games before, so it is likely that I don't know some
> > basics in that area.
> In the OpenGL case it is primary an effect of retrofitting thread-safety
> into existing APIs. Just like some systems retrofit many of the
> non-reentrant libc functions by using thread-local storage for the
> buffers.
> Joerg
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20171109/671abde1/attachment.html>

More information about the llvm-dev mailing list