[MIPS] Drop .dynsym symbol ordering requirement and nullify DT_GNU_XHASH

classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

[MIPS] Drop .dynsym symbol ordering requirement and nullify DT_GNU_XHASH

Fangrui Song-2
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)
Reply | Threaded
Open this post in threaded view
|

Re: [MIPS] Drop .dynsym symbol ordering requirement and nullify DT_GNU_XHASH

Maciej W. Rozycki
On Sat, 28 Dec 2019, Fangrui Song wrote:

> As I understand it, the benefits of the symbol ordering requirement come from
> the following:

 There are no benefits; the requirement comes from the GOT being relocated
implicitly (i.e. without the use of dynamic relocations, as it is usually
done, and based solely on dynamic entries providing ranges and then the
correlation between GOT entries and the corresponding dynsym entries), as
defined by the ELF MIPS psABI, long ago in mid 1990s when ELF was new and
people were still experimenting with it in various ways.

 You could lift the requirement, but it would be a significant ABI change,
requiring the addition of suitable dynamic relocations for GOT entries and
then updating toolchains and runtimes across the world.

 This would typically only be done with an otherwise major incompatible
change to the ABI, and it has actually been, for the nanoMIPS ISA.

 HTH,

  Maciej
Reply | Threaded
Open this post in threaded view
|

Re: [MIPS] Drop .dynsym symbol ordering requirement and nullify DT_GNU_XHASH

Maciej W. Rozycki
On Wed, 29 Jan 2020, Rich Felker wrote:

> >  You could lift the requirement, but it would be a significant ABI change,
> > requiring the addition of suitable dynamic relocations for GOT entries and
> > then updating toolchains and runtimes across the world.
> >
> >  This would typically only be done with an otherwise major incompatible
> > change to the ABI, and it has actually been, for the nanoMIPS ISA.
>
> I don't see how it requires any incompatible change. R_MIPS_REL32 is
> valid for non-PLT GOT slots and R_MIPS_JUMP_SLOT is valid for PLT
> ones.

 Well, we have no issue really with the PLTGOT in PLT executables (an
addition/extension to the original SVR4 MIPS psABI).

 What we have an "issue" with are SVR4 PIC binaries (both ET_EXEC and
ET_DYN ones, including PIE), as there are no relocations defined for local
GOT entries (no R_MIPS_RELATIVE or suchlike) or lazily resolved external
GOT entries, i.e. for which an SVR4 lazy binding stub has been assigned
(supposedly R_MIPS_JUMP_SLOT could be reused, but that has not been
defined at all in the original SVR4 MIPS psABI, nor the PLT extension did
define it for the purpose of SVR4 lazy binding stubs).

 For immediately resolved external GOT entries (i.e. for data symbols or
for function symbols whose address is taken for a purpose other than
making a call) I guess R_MIPS_REL32 could be reused, but then again it is
an ABI change that would require all the components to handle, as the GOT
is currently implicitly relocated.

 Also I'm not sure if that further complication is going to make things
better, as then not only you'll have to handle the original SVR4 MIPS
psABI binaries, but these new ones with explicitly relocated GOT as well.  
Which means more arcane platform code to maintain.  Why do you think it is
going to be beneficial?

  Maciej
Reply | Threaded
Open this post in threaded view
|

Re: [MIPS] Drop .dynsym symbol ordering requirement and nullify DT_GNU_XHASH

Maciej W. Rozycki
On Wed, 29 Jan 2020, Rich Felker wrote:

> >  Also I'm not sure if that further complication is going to make things
> > better, as then not only you'll have to handle the original SVR4 MIPS
> > psABI binaries, but these new ones with explicitly relocated GOT as well.  
> > Which means more arcane platform code to maintain.  Why do you think it is
> > going to be beneficial?
>
> Where do you mean more code to maintain? On the side of tools
> generating binaries, it's not clear to me what the net effect is; you
> avoid the need for new MIPS-specific GNU hash code, but have to add a
> code path to avoid use of the existing MIPS-specific implicit GOT and
> generate normal GOT slots instead. On the dynamic linker side, no new
> code whatsoever is needed; it just works (even with versions of the
> dynamic linker from before it was added).

 Yeah, I guess dynamic loading could just work by chance with the two
relocations; not that it was architected.

 However you do need to make a suitable change to the toolchain to be able
to produce the modified ELF structure and then keep existing code as well
for systems that require the old stuff.  Similarly to the current `-mplt'
option and its `-mno-plt' counterpart, and all the resulting hairy bits
especially in LD.

 Also as I say, that cannot handle the local part of the GOT, as we have
no MIPS relocation to express the desired relocation by the base address,
so you'll end up with hybrid images that are unlike other psABI stuff and
not like regular MIPS psABI stuff either.

  Maciej
Reply | Threaded
Open this post in threaded view
|

Re: [MIPS] Drop .dynsym symbol ordering requirement and nullify DT_GNU_XHASH

Rich Felker-2
On Fri, Jan 31, 2020 at 01:24:42PM +0000, Maciej W. Rozycki wrote:

> On Wed, 29 Jan 2020, Rich Felker wrote:
>
> > >  Also I'm not sure if that further complication is going to make things
> > > better, as then not only you'll have to handle the original SVR4 MIPS
> > > psABI binaries, but these new ones with explicitly relocated GOT as well.  
> > > Which means more arcane platform code to maintain.  Why do you think it is
> > > going to be beneficial?
> >
> > Where do you mean more code to maintain? On the side of tools
> > generating binaries, it's not clear to me what the net effect is; you
> > avoid the need for new MIPS-specific GNU hash code, but have to add a
> > code path to avoid use of the existing MIPS-specific implicit GOT and
> > generate normal GOT slots instead. On the dynamic linker side, no new
> > code whatsoever is needed; it just works (even with versions of the
> > dynamic linker from before it was added).
>
>  Yeah, I guess dynamic loading could just work by chance with the two
> relocations; not that it was architected.

If by "by chance" you mean "by the existing semantics" then yes.

>  However you do need to make a suitable change to the toolchain to be able
> to produce the modified ELF structure and then keep existing code as well
> for systems that require the old stuff.  Similarly to the current `-mplt'
> option and its `-mno-plt' counterpart, and all the resulting hairy bits
> especially in LD.
>
>  Also as I say, that cannot handle the local part of the GOT, as we have
> no MIPS relocation to express the desired relocation by the base address,

Yes we do. R_MIPS_REL32 without a symbol reference expresses that. All
archs necessarily have such a relocation because initialized data can
contain address constant expressions. Yes this overloading of meaning
is nasty but it's how mips has always worked. So no local part is
needed; the old implicit mips GOT can be completely omitted and still
yield a valid (supported by any existing tooling as long as no bugs
preclude it) binary. This could even be done regardless of whether gnu
hash is used, allowing all the old code to be removed and greatly
simplifying the tooling.

Rich