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: Fri, 31 Jan 2020 08:36:22 -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> <20200129220452.GO30412@brightrain.aerifal.cx> <alpine.LFD.2.21.2001311311380.330813@eddie.linux-mips.org>
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