We have an issue in the MIPS backend, with the handling of undefined
hidden and internal weak symbols. References to such symbols are
supposed to resolve to 0 according to the ELF gABI[1]:
"Unresolved weak symbols have a zero value."
and the 64-bit MIPS psABI[2]:
"If a symbol with one of these [hidden or internal] attributes has no
definition within the executable/DSO being linked, then it must be
resolved to allocated space if common, resolved to zero if weak, or an
error reported otherwise."
however if a GOT relocation is used, then a local GOT entry is created
and used to satisfy the reference. Such an entry is then (in DSO and
PIE binaries) subject to the usual load-time relocation, which means a
non-zero value will be returned if the base address is non-zero. This
will defeat the usual run-time sequence like:
void a (void) __attribute__ ((visibility ("hidden"), weak));
void
x (void)
{
if (a)
a ();
}
This can be reproduced with this simple code:
$ cat libtest.c
extern int a __attribute__ ((visibility ("hidden"), weak));
int *
x (void)
{
return &a;
}
$ cat test.c
int *x (void);
int
main (void)
{
printf ("a: %p\n", x ());
return 0;
}
$ gcc -shared -fPIC -o libtest.so libtest.c
$ gcc -o test test.c -Wl,-rpath,$(pwd) libtest.so
$ ./test
a: 0x77184000
$
The usual approach targets take is making all the steps required to
assign a GOT entry for the symbol referred, and then leave its contents
at zero with no dynamic relocation attached, therefore ensuring that the
value does not change at load time. However this is not going to work
with the implicitly relocated GOT the MIPS psABI specifies[3]:
"The dynamic linker relocates the global offset table by first adding
the difference between the base where the shared object is loaded and
the value of the dynamic tag DT_MIPS_BASE_ADDRESS to all local global
offset table entries."
and we cannot therefore use the local GOT part.
And we cannot offhand use the global part either, as the symbol would
then have to be exported and possibly wrongly preempt symbols in other
modules involved in the dynamic load, because as per the ELF gABI[1] we
are not allowed to enter a hidden or internal symbol into the dynamic
symbol table (and then use its associated GOT entry):
"A hidden symbol contained in a relocatable object must be either
removed or converted to STB_LOCAL binding by the link-editor when the
relocatable object is included in an executable file or shared object."
and:
"An internal symbol contained in a relocatable object must be either
removed or converted to STB_LOCAL binding by the link-editor when the
relocatable object is included in an executable file or shared object."
So we have to choose something else.
Our choice is further limited by the need for the reference associated
with the GOT relocation to stay within the signed 16-bit limit from the
GOT pointer base register, while being compliant with the ELF gABI and
the MIPS psABI. However as Alan Modra has observed[4] one possibility
is to edit (relax) the code such that the GOT reference is removed
altogether.
Based on these observations then modify MIPS BFD linker backend code to:
1. Interpret code associated with GOT relocations and relax the usual LW
or LD instructions into a corresponding immediate load operation that
places the value of 0 in the intended register, while leaving the GOT
entry allocated and initialized as usually.
2. Leave any other instructions associated with GOT relocations in place
and instead redirect the reference to a global GOT entry associated
with a special `__gnu_absolute_zero' symbol created for this purpose,
whose value is 0, SHN_ABS section marks it absolute, binding is
global and export class protected, ensuring that the locally provided
value is always used at load time, and that the value is not
relocated by the dynamic loader.
3. Adjust any high-part GOT relocation used, typically associated with
a LUI instruction, accordingly, so that run-time consistency is
maintained, either by resolving to the original entry if the
instruction associated with the corresponding low-part GOT relocation
has been relaxed to an immediate load (in which case the value loaded
with LUI will be overwritten), or by also redirecting the reference
to `__gnu_absolute_zero' to complete the GOT access sequence if that
symbol has been used.
4. Add a target `elf_backend_hide_symbol' hook, for the three MIPS ABIs,
which prevents the `__gnu_absolute_zero' symbol from being forced
local, to ensure that the redirection works and the symbol remains
global/protected with existing linker scripts unchanged.
5. Observing the issue with handling SHN_ABS symbols in the GNU dynamic
loader, covered by glibc PR 19818, set the EI_ABIVERSION field in the
ELF file header produced to 4 (ABI_ABSOLUTE) if `__gnu_absolute_zero'
symbol has been produced and the target configured indicates the GNU
operating system, so that broken versions of the GNU dynamic loader
gracefully reject the file in loading rather than going astray. Keep
EI_ABIVERSION at the original value for other operating systems or if
no `__gnu_absolute_zero' symbol has been made.
The name of the special `__gnu_absolute_zero' has no meaning other than
how a human reader can interpret it, as it is ignored in dynamic loading
in the handling of the scenarios concerned. This is because the symbol
resolves locally, and it's only the symbol's attributes that matter so
that the associated GOT entry remains unchanged at load time.
Therefore the name is somewhat arbitrary, observing however the need to
use the name space reserved for the system so that it does not conflict
with a possible user symbol, and hence the leading underscore, and also
the `gnu' infix to denote a GNU feature. Other implementations wishing
to address the problem in a similar way may choose a different name and
have the solution still work, possibly with a mixture of modules used in
a dynamic having symbols of different names provided, which will however
not interact with each other due to the protected export class.
The symbol can be referred explicitly, however the name is an internal
implementation detail rather than a part of the ABI, and therefore no
specific semantics is guaranteed.
One limitation of this change is that if `__gnu_absolute_zero' has been
already defined, then we do not wipe the old definition and all kinds of
odd behavior can result. This is however like with other symbols we
internally define, such as `_GLOBAL_OFFSET_TABLE_' or `__rld_map', and
therefore left as a possible future enhancement.
As an optimization the relaxation of LW and LD instructions to a load of
immediate zero is always made, even SVR4 PIC code for code that will end
up in a regular (non-PIE) executable, because there is a cache advantage
with the avoidance of a load from the GOT, even if it is otherwise
guaranteed to remain zero. It does not reliably happen though, due to a
symbol exportation issue affecting executables, covered by PR ld/21805.
One existing test case needs to be updated, as it triggers relaxation
introduced with this change and consequently linker output does not
match expectations anymore. As we want to keep the original issue
covered with the test case modify it then to use the LWL instruction in
place of LW, and adjust the output expected accordingly.
References:
[1] "System V Application Binary Interface - DRAFT - 19 October 2010",
The SCO Group, Section "Symbol Table",
<http://www.sco.com/developers/gabi/2012-12-31/ch4.symtab.html>
[2] "64-bit ELF Object File Specification, Draft Version 2.5", MIPS
Technologies / Silicon Graphics Computer Systems, Order Number
007-4658-001, Section 2.5 "Symbol Table", p. 22,
<http://techpubs.sgi.com/library/manuals/4000/007-4658-001/pdf/007-4658-001.pdf>
[3] "SYSTEM V APPLICATION BINARY INTERFACE, MIPS RISC Processor
Supplement, 3rd Edition", Section "Global Offset Table", p. 5-10,
<http://www.linux-mips.org/pub/linux/mips/doc/ABI/mipsabi.pdf>
[4] "Undo dynamic symbol state after regular object sym type mismatch",
<https://sourceware.org/ml/binutils/2017-07/msg00265.html>
bfd/
PR ld/21375
* elfxx-mips.h (_bfd_mips_elf_hide_symbol): New prototype.
(_bfd_mips_elf_linker_flags): Update prototype.
* elf32-mips.c (elf_backend_hide_symbol): New macro.
* elf64-mips.c (elf_backend_hide_symbol): Likewise.
* elfn32-mips.c (elf_backend_hide_symbol): Likewise.
* elfxx-mips.c (mips_elf_link_hash_table): Add
`use_absolute_zero' and `gnu_target' members.
(mips_elf_record_global_got_symbol): Call
`_bfd_mips_elf_hide_symbol' rather than
`_bfd_elf_link_hash_hide_symbol'.
(mips_use_local_got_p): Return FALSE if the symbol is absolute.
(mips_elf_obtain_contents): Reorder function.
(mips_elf_nullify_got_load): New function.
(mips_elf_calculate_relocation): Add `contents' parameter.
Nullify GOT loads or if it is not possible, then redirect GOT
relocations to the `__gnu_absolute_zero' symbol, for references
that are supposed to resolve to zero.
(mips_elf_define_absolute_zero): New function.
(_bfd_mips_elf_check_relocs): Prepare for arrangements made in
`mips_elf_calculate_relocation' for references made via the GOT
that are supposed to resolve to zero.
(_bfd_mips_elf_hide_symbol): New function.
(_bfd_mips_elf_linker_flags): Add the `gnu_target' parameter,
set the `gnu_target' member of the MIPS hash table.
(MIPS_LIBC_ABI_ABSOLUTE): New enumeration constant.
(_bfd_mips_post_process_headers): Use it.
ld/
PR ld/21375
* emultempl/mipself.em: Set `gnu_target' according to ${target}.
(mips_create_output_section_statements): Update call to
`_bfd_mips_elf_linker_flags'.
* testsuite/ld-mips-elf/pr21334.s: Use LWL rather than LW.
* testsuite/ld-mips-elf/pr21334.dd: Update accordingly.
This file contains invisible Unicode characters that are indistinguishable to humans but may be processed differently by a computer. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.
BFD is an object file library. It permits applications to use the
same routines to process object files regardless of their format.
BFD is used by the GNU debugger, assembler, linker, and the binary
utilities.
The documentation on using BFD is scanty and may be occasionally
incorrect. Pointers to documentation problems, or an entirely
rewritten manual, would be appreciated.
There is some BFD internals documentation in doc/bfdint.texi which may
help programmers who want to modify BFD.
BFD is normally built as part of another package. See the build
instructions for that package, probably in a README file in the
appropriate directory.
BFD supports the following configure options:
--target=TARGET
The default target for which to build the library. TARGET is
a configuration target triplet, such as sparc-sun-solaris.
--enable-targets=TARGET,TARGET,TARGET...
Additional targets the library should support. To include
support for all known targets, use --enable-targets=all.
--enable-64-bit-bfd
Include support for 64 bit targets. This is automatically
turned on if you explicitly request a 64 bit target, but not
for --enable-targets=all. This requires a compiler with a 64
bit integer type, such as gcc.
--enable-shared
Build BFD as a shared library.
--with-mmap
Use mmap when accessing files. This is faster on some hosts,
but slower on others. It may not work on all hosts.
Report bugs with BFD to bug-binutils@gnu.org.
Patches are encouraged. When sending patches, always send the output
of diff -u or diff -c from the original file to the new file. Do not
send default diff output. Do not make the diff from the new file to
the original file. Remember that any patch must not break other
systems. Remember that BFD must support cross compilation from any
host to any target, so patches which use ``#ifdef HOST'' are not
acceptable. Please also read the ``Reporting Bugs'' section of the
gcc manual.
Bug reports without patches will be remembered, but they may never get
fixed until somebody volunteers to fix them.
Copyright (C) 2012-2018 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.
47275900ad