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: Rich Felker <dalias at libc dot org>
- To: "Maciej W. Rozycki" <macro at linux-mips 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 17:04:52 -0500
- 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> <alpine.LFD.2.21.2001292124080.2508990@eddie.linux-mips.org>
On Wed, Jan 29, 2020 at 09:58:06PM +0000, Maciej W. Rozycki wrote:
> 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?
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).
Rich