This is the mail archive of the
binutils@sourceware.org
mailing list for the binutils project.
[MIPS] Drop .dynsym symbol ordering requirement and nullify DT_GNU_XHASH
- From: Fangrui Song <i at maskray dot me>
- To: libc-alpha at sourceware dot org, binutils at sourceware dot org
- Cc: Nick Clifton <nickc at redhat dot com>, Joseph Myers <joseph at codesourcery dot com>, Adhemerval Zanella <adhemerval dot zanella at linaro dot org>, "Maciej W . Rozycki" <macro at linux-mips dot org>, Carlos O'Donell <carlos at redhat dot com>, Dragan Mladjenovic <dragan dot mladjenovic at rt-rk dot com>, Petar Jovanovic <petar dot jovanovic at rt-rk dot com>, Mihailo Stojanovic <mihailo dot stojanovic at rt-rk dot com>, Sava Jakovljev <sava dot jakovljev at rt-rk dot com>, Rich Felker <dalias at libc dot org>, Cary Coutant <ccoutant at gmail dot com>, Simon Atanasyan <simon at atanasyan dot com>
- Date: Sat, 28 Dec 2019 12:45:12 -0800
- Subject: [MIPS] Drop .dynsym symbol ordering requirement and nullify DT_GNU_XHASH
In August 2019, GNU ld gained support for DT_GNU_XHASH [1] (DT_GNU_HASH with an additional symbol index translation table (xlat)).
A gold patch [2] was posted but has not been applied.
https://sourceware.org/git/?p=glibc.git;a=commit;h=23c1c256ae7b0f010d0fcaff60682b620887b164 added glibc ld.so support.
Instead of diverging more from other architectures, I wonder whether we can drop .dynsym symbol ordering requirement, and just use regular DT_GNU_HASH. To this end, DT_MIPS_GOTSYM=DT_MIPS_SYMTABNO and DT_MIPS_LOCAL_GOTNO=0 should be sufficient for musl [3].
As I understand it, the benefits of the symbol ordering requirement come from the following:
1. DT_MIPS_LOCAL_GOTNO relative relocation entries are saved. Relative relocations are common for -pie, but I really doubt the efficiency of DT_MIPS_LOCAL_GOTNO. Many relative relocations are not associated with a dynamic symbol. Adopting the unofficial SHT_RELR/DT_RELR [4] may be more beneficial.
2. DT_MIPS_SYMTABNO-DT_MIPS_GOTSYM words are saved for JUMP_SLOT. The saving is also questionable because the number of JUMP_SLOT is usually small.
3. The DT_GNU_XHASH translation table seems to partly defeat the size saving purposes of 2. :)
Other than DT_MIPS_GOTSYM=DT_MIPS_SYMTABNO and DT_MIPS_LOCAL_GOTNO=0, I don't know whether glibc ld.so needs more things so that old ld.so can refuse new executables/shared objects. There may be multiple ways. I confess I don't understand the matters and MIPS enough, but something that jumped into my mind: bumping EI_ABIVERSION, introducing a new dynamic tag DT_MIPS_DYNSYM (think ppc32 Secure-PLT DT_PPC_GOT), .MIPS.abiflags, etc.
(
DT_GNU_XHASH may complicate --hash-style=gnu --hash-style=both semantics in clang driver/gcc specs as well.)
PS: I am not a MIPS user. I just don't want to see more ELF hacks invented to further complicate toolchains...
)
[1]: binutils support https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;a=commit;h=f16a9783c5f085443d806646074e9c06fdee9a88
https://sourceware.org/ml/binutils/2019-08/msg00092.html
[2]: gold patch https://sourceware.org/ml/binutils/2019-07/msg00227.html
[3]: musl ld.so https://git.musl-libc.org/cgit/musl/tree/ldso/dynlink.c?id=d01fdc777dd3b5ebcad351ee47d1984d28db31e4#n1297
[4]: SHT_RELR/DT_RELR https://groups.google.com/forum/#!search/SHT_RELR/generic-abi/bX460iggiKg/w95-EVqFBAAJ supported by llvm-readelf / lld (--pack-dyn-relocs=relr; https://reviews.llvm.org/D48247)