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

Kristof Beyls kristof.beyls at arm.com
Fri Feb 27 06:49:07 PST 2015


Hi Jing,

Thanks for the background info.

I've got a patch in review to fix the issues in how LLVM produces the
TLS accesses, and working around limited support in current GNU
linkers for some of the relocations, see http://reviews.llvm.org/D7677.

For gold, support for the following 2 relocations that LLVM can generate
after the above patch gets implemented, seems to be missing:
* R_AARCH64_TLSLD_ ADD_DTPREL_HI12 (528)
* R_AARCH64_TLSLD_ ADD_DTPREL_LO12_NC (530)

Would you be able to add support for these in gold?

I'm in touch with the ARM GNU engineers to get the relocations missing 
in ld.bfd and generated by LLVM implemented.

Thanks,

Kristof

> -----Original Message-----
> From: Jing Yu [mailto:jingyu at google.com]
> Sent: 29 January 2015 22:33
> To: Kristof Beyls
> Cc: Eric Christopher; Chandler Carruth; Hans Wennborg; 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,
> 
> 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








More information about the llvm-commits mailing list