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

[Jing Yu]

Hi Kristof,

You are right. Neither bfd.ld nor gold supports all AArch64
relocations. I guess the reason is that there are too many (>180) and
compiler only uses a few of them.
When we were working on gold aarch64 port, we only looked at what
bfd.ld supports and what GCC is generating.

As for TLS support, I noticed that GCC only generates code for general
dynamic model and TLS descriptor model, and linker optimizes these
into LE or IE access. TLSLD model was not supported by gnu tools until
Eric pointed out that Clang actually uses it and Will Newton from
Linaro finally added TLSLD support into objdump, and I added it into
gold.

I did not read Clang code. From your experiment, I see reloc 545 and
reloc 548 are missing by gold. Did you notice other TLS relocations
that are used by Clang but not by GCC? Have you asked Linaro whether
they have a plan to add support for them into GNU tools?

Thanks!
Jing

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