mirror of
https://sourceware.org/git/binutils-gdb.git
synced 2024-12-15 04:31:49 +08:00
976f16630b
In aarch64_tls_transition_without_check and elfNN_aarch64_tls_relax we choose whether to perform a relaxation to an IE access model or an LE access model based on whether the symbol itself is marked as local (i.e. `h == NULL`). This is problematic in two ways. The first is that sometimes a global dynamic access can be relaxed to an initial exec access when creating a shared library, and if that happens on a local symbol then we currently relax it to a local exec access instead. This usually does not happen since we only relax an access if aarch64_can_relax_tls returns true and aarch64_can_relax_tls does not have the same problem. However, it can happen when we have seen both an IE and GD access on the same symbol. This case is exercised in the newly added testcase tls-relax-gd-ie-2. The second problem is that deciding based on whether the symbol is local misses the case when the symbol is global but is still non-interposable and known to be located in the executable. This happens on all global symbols in executables. This case is exercised in the newly added testcase tls-relax-ie-le-4. Here we adjust the condition we base our relaxation on so that we relax to local-exec if we are creating an executable and the relevant symbol we're accessing is stored inside that executable. -- Updating tests for new relaxation criteria Many of the tests added to check our relaxation to IE were implemented by taking advantage of the fact that we did not relax a global symbol defined in an executable. Since a global symbol defined in an executable is still not interposable, we know that a TLS version of such a symbol will be in the main TLS block. This means that we can perform a stronger relaxation on such symbols and relax their accesses to a local-exec access. Hence we have to update all tests that relied on the older suboptimal decision making. The two cases when we still would want to relax a general dynamic access to an initial exec one are: 1) When in a shared library and accessing a symbol which we have already seen accessed with an initial exec access sequence. 2) When in an executable and accessing a symbol defined in a shared library. Both of these require shared library support, which means that these tests are now only available on targets with that. I have chosen to switch the existing testcases from a plain executable to one dynamically linked to a shared object as that doesn't require changing the testcases quite so much (just requires accessing a different variable rather than requiring adding another code sequence). The tls-relax-all testcase was an outlier to the above approach, since it included a general dynamic access to both a local and global symbol and inspected for the difference accordingly. |
||
---|---|---|
.. | ||
emulparams | ||
emultempl | ||
po | ||
scripttempl | ||
testsuite | ||
.gitignore | ||
aclocal.m4 | ||
ChangeLog | ||
ChangeLog-0001 | ||
ChangeLog-0203 | ||
ChangeLog-2004 | ||
ChangeLog-2005 | ||
ChangeLog-2006 | ||
ChangeLog-2007 | ||
ChangeLog-2008 | ||
ChangeLog-2009 | ||
ChangeLog-2010 | ||
ChangeLog-2011 | ||
ChangeLog-2012 | ||
ChangeLog-2013 | ||
ChangeLog-2014 | ||
ChangeLog-2015 | ||
ChangeLog-2016 | ||
ChangeLog-2017 | ||
ChangeLog-2018 | ||
ChangeLog-2019 | ||
ChangeLog-2020 | ||
ChangeLog-9197 | ||
ChangeLog-9899 | ||
config.in | ||
configure | ||
configure.ac | ||
configure.host | ||
configure.tgt | ||
deffile.h | ||
deffilep.y | ||
dep-in.sed | ||
elf-hints-local.h | ||
fdl.texi | ||
gen-doc.texi | ||
genscrba.sh | ||
genscripts.sh | ||
h8-doc.texi | ||
ld.h | ||
ld.texi | ||
ldbuildid.c | ||
ldbuildid.h | ||
ldcref.c | ||
ldctor.c | ||
ldctor.h | ||
ldelf.c | ||
ldelf.h | ||
ldelfgen.c | ||
ldelfgen.h | ||
ldemul.c | ||
ldemul.h | ||
ldexp.c | ||
ldexp.h | ||
ldfile.c | ||
ldfile.h | ||
ldgram.y | ||
ldint.texi | ||
ldlang.c | ||
ldlang.h | ||
ldlex-wrapper.c | ||
ldlex.h | ||
ldlex.l | ||
ldmain.c | ||
ldmain.h | ||
ldmisc.c | ||
ldmisc.h | ||
ldver.c | ||
ldver.h | ||
ldwrite.c | ||
ldwrite.h | ||
lexsup.c | ||
libdep_plugin.c | ||
MAINTAINERS | ||
Makefile.am | ||
Makefile.in | ||
mri.c | ||
mri.h | ||
NEWS | ||
pe-dll.c | ||
pe-dll.h | ||
pep-dll.c | ||
pep-dll.h | ||
plugin.c | ||
plugin.h | ||
README | ||
sysdep.h | ||
testplug2.c | ||
testplug3.c | ||
testplug4.c | ||
testplug.c | ||
TODO |
README for LD
This is the GNU linker. It is distributed with other "binary
utilities" which should be in ../binutils. See ../binutils/README for
more general notes, including where to send bug reports.
There are many features of the linker:
* The linker uses a Binary File Descriptor library (../bfd)
that it uses to read and write object files. This helps
insulate the linker itself from the format of object files.
* The linker supports a number of different object file
formats. It can even handle multiple formats at once:
Read two input formats and write a third.
* The linker can be configured for cross-linking.
* The linker supports a control language.
* There is a user manual (ld.texi), as well as the
beginnings of an internals manual (ldint.texi).
Installation
============
See ../binutils/README.
If you want to make a cross-linker, you may want to specify
a different search path of -lfoo libraries than the default.
You can do this by setting the LIB_PATH variable in ./Makefile
or using the --with-lib-path configure switch.
To build just the linker, make the target all-ld from the top level
directory (one directory above this one).
Porting to a new target
=======================
See the ldint.texi manual.
Reporting bugs etc
===========================
See ../binutils/README.
Known problems
==============
The Solaris linker normally exports all dynamic symbols from an
executable. The GNU linker does not do this by default. This is
because the GNU linker tries to present the same interface for all
similar targets (in this case, all native ELF targets). This does not
matter for normal programs, but it can make a difference for programs
which try to dlopen an executable, such as PERL or Tcl. You can make
the GNU linker export all dynamic symbols with the -E or
--export-dynamic command line option.
HP/UX 9.01 has a shell bug that causes the linker scripts to be
generated incorrectly. The symptom of this appears to be "fatal error
- scanner input buffer overflow" error messages. There are various
workarounds to this:
* Build and install bash, and build with "make SHELL=bash".
* Update to a version of HP/UX with a working shell (e.g., 9.05).
* Replace "(. ${srcdir}/scripttempl/${SCRIPT_NAME}.sc)" in
genscripts.sh with "sh ${srcdir}..." (no parens) and make sure the
emulparams script used exports any shell variables it sets.
Copyright (C) 2012-2022 Free Software Foundation, Inc.
Copying and distribution of this file, with or without modification,
are permitted in any medium without royalty provided the copyright
notice and this notice are preserved.