diff options
author | Maciej W. Rozycki <macro@mips.com> | 2018-04-04 23:09:37 +0100 |
---|---|---|
committer | Maciej W. Rozycki <macro@mips.com> | 2018-04-04 23:09:37 +0100 |
commit | e7feec374c635b6a29d65c39ae5e1855528fed39 (patch) | |
tree | 66022e087f86c5dde38a9e6b565565d4e909f60c /sysdeps | |
parent | 10a446ddcc1100d6d76c6aa0c6d4775209388152 (diff) | |
download | glibc-e7feec374c635b6a29d65c39ae5e1855528fed39.zip glibc-e7feec374c635b6a29d65c39ae5e1855528fed39.tar.gz glibc-e7feec374c635b6a29d65c39ae5e1855528fed39.tar.bz2 |
elf: Correct absolute (SHN_ABS) symbol run-time calculation [BZ #19818]
Do not relocate absolute symbols by the base address. Such symbols have
SHN_ABS as the section index and their value is not supposed to be
affected by relocation as per the ELF gABI[1]:
"SHN_ABS
The symbol has an absolute value that will not change because of
relocation."
The reason for our non-conformance here seems to be an old SysV linker
bug causing symbols like _DYNAMIC to be incorrectly emitted as absolute
symbols[2]. However in a previous discussion it was pointed that this
is seriously flawed by preventing the lone purpose of the existence of
absolute symbols from being used[3]:
"On the contrary, the only interpretation that makes sense to me is that
it will not change because of relocation at link time or at load time.
Absolute symbols, from the days of the earliest linking loaders, have
been used to represent addresses that are outside the address space of
the module (e.g., memory-mapped addresses or kernel gateway pages).
They've even been used to represent true symbolic constants (e.g.,
system entry point numbers, sizes, version numbers). There's no other
way to represent a true absolute symbol, while the meaning you seek is
easily represented by giving the symbol a non-negative st_shndx value."
and we ought to stop supporting our current broken interpretation.
Update processing for dladdr(3) and dladdr1(3) so that SHN_ABS symbols
are ignored, because under the corrected interpretation they do not
represent addresses within a mapped file and therefore are not supposed
to be considered.
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] Alan Modra, "Absolute symbols"
<https://sourceware.org/ml/binutils/2012-05/msg00019.html>
[3] Cary Coutant, "Re: Absolute symbols"
<https://sourceware.org/ml/binutils/2012-05/msg00020.html>
[BZ #19818]
* sysdeps/generic/ldsodefs.h (SYMBOL_ADDRESS): Handle SHN_ABS
symbols.
* elf/dl-addr.c (determine_info): Ignore SHN_ABS symbols.
* elf/tst-absolute-sym.c: New file.
* elf/tst-absolute-sym-lib.c: New file.
* elf/tst-absolute-sym-lib.lds: New file.
* elf/Makefile (tests): Add `tst-absolute-sym'.
(modules-names): Add `tst-absolute-sym-lib'.
(LDLIBS-tst-absolute-sym-lib.so): New variable.
($(objpfx)tst-absolute-sym-lib.so): New dependency.
($(objpfx)tst-absolute-sym): New dependency.
Diffstat (limited to 'sysdeps')
-rw-r--r-- | sysdeps/generic/ldsodefs.h | 3 |
1 files changed, 2 insertions, 1 deletions
diff --git a/sysdeps/generic/ldsodefs.h b/sysdeps/generic/ldsodefs.h index 3cac4fa..95dc875 100644 --- a/sysdeps/generic/ldsodefs.h +++ b/sysdeps/generic/ldsodefs.h @@ -72,7 +72,8 @@ typedef struct link_map *lookup_t; if non-NULL. Don't check for NULL map if MAP_SET is TRUE. */ #define SYMBOL_ADDRESS(map, ref, map_set) \ ((ref) == NULL ? 0 \ - : LOOKUP_VALUE_ADDRESS (map, map_set) + (ref)->st_value) + : (__glibc_unlikely ((ref)->st_shndx == SHN_ABS) ? 0 \ + : LOOKUP_VALUE_ADDRESS (map, map_set)) + (ref)->st_value) /* On some architectures a pointer to a function is not just a pointer to the actual code of the function but rather an architecture |