[llvm] r227411 - [LPM] Clean up the use of TLS in pretty stack trace and disable it

[Chandler Carruth]

>From your emails and experiments, my impression is that there is something
about Clang/LLVM that is buggy w.r.t. TLS on AArch64 -- GCC seems to do OK.

>From that, my suggestion is to see what is required to fix it. AArch64 is a
really new host, and so it's not completely surprising that there would be
some problems. If there is a reasonably easy way to fix Clang's output to
at least match GCC's output, then I think the TLS stuff should stay, stay
in 3.6, and we should backport that fix. Note that you can always bootstrap
without threads to pick up such fixes.

My reasoning is that the TLS usage in the pretty stack printing is actually
a pretty nice compile time win that I wouldn't want to lose. When compiling
lots of small files with clang (like, say, a configure script does) this
can add up to 1% or a lot more.

On Thu, Jan 29, 2015 at 11:44 AM, Kristof Beyls <kristof.beyls at arm.com>
wrote:

> Hi Eric,
>
>
>
> I’ve experimented a bit with a **very** simple program using a TLS
> variable.
>
> It seems to me that in binutils 2.25, ld.bfd supports non-PIC compiled
> code and ld.gold support PIC-compiled code.
> But neither supports both PIC and non-PIC compiled TLS variables.
>
> For details of my experiments, see below.
>
>
>
> $ cat t3.cpp
>
> static volatile thread_local int tls_i;
>
>
>
> int main() {
>
>   tls_i = 4;
>
>   return tls_i;
>
> }
>
> # Works with g++ 4.9.1:
>
> $ g++ -O3 -std=c++11 -o t3_g++-4.9.1_O3 t3.cpp
>
> # breaks with clang++-3.5 in combination with gold 2.25:
>
> $ clang++-3.5 -O3 -std=c++11 -o t3_clang++-3.5_O3 t3.cpp -Wl,-v
>
> GNU gold (GNU Binutils for Debian 2.25) 1.11
>
> /usr/bin/ld: error: /tmp/t3-4c39c0.o: unsupported reloc 545 against local
> symbol
>
> /usr/bin/ld: error: /tmp/t3-4c39c0.o: unsupported reloc 548 against local
> symbol
>
> /tmp/t3-4c39c0.o:t3.cpp:function main: error: cannot relocate invalid
> reloc 545 in object file
>
> /tmp/t3-4c39c0.o:t3.cpp:function main: error: cannot relocate invalid
> reloc 548 in object file
>
> clang: error: linker command failed with exit code 1 (use -v to see
> invocation)
>
> # works with clang++-3.5 and ld.bfd 2.25:
>
> $ clang++-3.5 -O3 -std=c++11 -o t3_clang++-3.5_O3 t3.cpp -Wl,-v
> -fuse-ld=bfd
>
> GNU ld (GNU Binutils for Debian) 2.25
>
> llvm-test at llvm-farm-juno-5:~/kristof$ ./t3_clang++-3.5_O3; echo $?
>
> 4
>
> # SUMMARY: so far, gold doesn’t support some TLS relocations that clang
> produces.
>
> # Try another example to show the problem with ld.bfd, on relocation
> 0x20c=524=R_AARCH64_TLSLD_MOVW_DTPREL_G1:
>
> clang++-3.5 -fPIC -O3 -std=c++11 -o t3_clang++-3.5_O3 t3.cpp -Wl,-v
> -fuse-ld=bfd
>
> GNU ld (GNU Binutils for Debian) 2.25
>
> /usr/bin/ld.bfd: /tmp/t3-3b0353.o: unrecognized relocation (0x20c) in
> section `.text'
>
> /usr/bin/ld.bfd: final link failed: Bad value
>
> clang: error: linker command failed with exit code 1 (use -v to see
> invocation)
>
> llvm-test at llvm-farm-juno-5:~/kristof$ clang++-3.5 -fPIC -O3 -std=c++11 -o
> t3_clang++-3.5_O3 t3.cpp -Wl,-v
>
> GNU gold (GNU Binutils for Debian 2.25) 1.11
>
>
>
>
>
> *From:* Eric Christopher [mailto:echristo at gmail.com]
> *Sent:* 29 January 2015 19:38
> *To:* Kristof Beyls; Chandler Carruth; Hans Wennborg; jingyu at google.com
>
> *Cc:* Commit Messages and Patches for LLVM
> *Subject:* Re: [llvm] r227411 - [LPM] Clean up the use of TLS in pretty
> stack trace and disable it
>
>
>
> Hi Kristof,
>
>
>
> I know Jing (on this email) was working on gold tls relocations when I
> noticed this a while back. I'm pretty sure she implemented them (at least I
> can link now), but I'm not sure how well it's working. Can you confirm or
> elaborate more?
>
>
>
> -eric
>
>
>
> On Thu Jan 29 2015 at 11:25:23 AM Kristof Beyls <kristof.beyls at arm.com>
> wrote:
>
> For AArch64, clang produces relocations for TLS variables that ld.bfd or
> ld.gold can’t handle.
>
> It seems that gcc, ld and gas only support the “small memory model 16Mib
> TLS address model”,
> and AFAIK, it may take a while for these to grow support for other address
> models.
>
>
>
> I haven’t had time to come fully up to speed on this, but at the moment,
> the only workable
> solution I can think of is to:
>
> ·         Not use thread_local variables in LLVM for the 3.6 release on
> AArch64, so that clang 3.6
> can bootstrap itself on AArch64-linux.
>
> ·         On trunk, let clang targeting AArch64-ELF systems only produce
> the relocations that ld supports.
> At first sight that seems possible, but I’m not sure.
>
>
>
> Does anyone have a better set of suggestions than the above?
>
>
>
> Thanks,
>
>
>
> Kristof
>
>
>
> *From:* llvm-commits-bounces at cs.uiuc.edu [mailto:
> llvm-commits-bounces at cs.uiuc.edu] *On Behalf Of *Chandler Carruth
> *Sent:* 29 January 2015 18:59
> *To:* Hans Wennborg
> *Cc:* Commit Messages and Patches for LLVM
> *Subject:* Re: [llvm] r227411 - [LPM] Clean up the use of TLS in pretty
> stack trace and disable it
>
>
>
> I'm still waiting for some of the dust to settle with ppc and arm. I'll
> have a list before long and can help merge.
>
> On Jan 29, 2015 9:50 AM, "Hans Wennborg" <hans at chromium.org> wrote:
>
> On Wed, Jan 28, 2015 at 5:23 PM, Chandler Carruth <chandlerc at gmail.com>
> wrote:
> > Author: chandlerc
> > Date: Wed Jan 28 19:23:04 2015
> > New Revision: 227411
> >
> > URL: http://llvm.org/viewvc/llvm-project?rev=227411&view=rev
> > Log:
> > [LPM] Clean up the use of TLS in pretty stack trace and disable it
> > entirely when threads are not enabled. This should allow anyone who
> > needs to bootstrap or cope with a host loader without TLS support to
> > limp along without threading support.
>
> I assume we want this (and r227412) for the 3.6 branch. Any others?
> _______________________________________________
> llvm-commits mailing list
> llvm-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
>
> _______________________________________________
> llvm-commits mailing list
> llvm-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
>
> _______________________________________________
> llvm-commits mailing list
> llvm-commits at cs.uiuc.edu
> http://lists.cs.uiuc.edu/mailman/listinfo/llvm-commits
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20150129/aac0fdb1/attachment.html>