This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [MIPS] Drop .dynsym symbol ordering requirement and nullify DT_GNU_XHASH
- From: "Maciej W. Rozycki" <macro at linux-mips dot org>
- To: Rich Felker <dalias at libc dot org>
- Cc: Fangrui Song <i at maskray dot me>, libc-alpha at sourceware dot org, binutils at sourceware dot org, Nick Clifton <nickc at redhat dot com>, Joseph Myers <joseph at codesourcery dot com>, Adhemerval Zanella <adhemerval dot zanella at linaro 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>, Cary Coutant <ccoutant at gmail dot com>, Simon Atanasyan <simon at atanasyan dot com>
- Date: Wed, 29 Jan 2020 21:58:06 +0000 (GMT)
- Subject: Re: [MIPS] Drop .dynsym symbol ordering requirement and nullify DT_GNU_XHASH
- References: <20191228204512.4nguaqanafgbkots@gmail.com> <alpine.LFD.2.21.2001291845050.2508990@eddie.linux-mips.org> <20200129210559.GL30412@brightrain.aerifal.cx>
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