This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Multiarch interpreter names for traditional architectures
On Fri, 9 Feb 2018, Joseph Myers wrote:
> > However microMIPS hardware may not support regular MIPS code execution
> > (and vice versa) and therefore I think it has to be treated as a different
> > ABI. Placing microMIPS ld.so where regular MIPS ld.so is expected will
> > break if the installation is shared via NFS between pure regular MIPS and
> > pure microMIPS hardware.
>
> But the execution of both might be supported on the same hardware. We
> don't consider x86_64 with AVX512 enabled to be a separate ABI from plain
> x86_64 (and indeed some libmvec entry points may require instruction set
> features beyond the base ISA).
I think this is not a good analogy. The thing is there is no standalone
AVX512 ISA -- that is you can't have a piece of hardware that only
implements AVX512 and not the base x86_64 ISA. This is analogous to the
relationship between the regular MIPS ISA and the MIPS16 extension, which
I have agreed are a part of the same ABI.
Whereas the microMIPS ISA is standalone and you can have hardware that
has only the microMIPS ISA implemented and not the regular MIPS ISA (and
vice versa of course).
> Effectively some things are the same ABI in that some hardware might run
> both and if it does, those things are compatible (no need for the dynamic
> linker to reject loading both together, no need for different dynamic
> linker paths since a binary might be built for the common subset). While
> it would be reasonable for the dynamic linker also to be able to reject
> loading objects that require instruction set features not supported by the
> hardware (modulo being able to build for IFUNCs and other dynamic choice
> of function implementations and not mark the resulting objects as
> requiring those features), even when the ABI is the same.
Well, if you consider the regular MIPS ISA and the microMIPS ISA a part
of the same ABI, then ld.so may not be able to run in the first place if
hardware does not implement the ISA, either of the two, the loader has
been built for, so it cannot even be considered if it is able to load
things together. So this contradicts your assertion that "a binary might
be built for the common subset", because no such common subset exists
between the regular MIPS ISA and the microMIPS ISA.
You need at least a separate regular MIPS loader for regular MIPS
executables and a separate microMIPS loader for microMIPS executables for
userland software to be guaranteed to run. Then either of those loaders
started will be able to decide what else required can be loaded or not.
With the above observations in mind do you still think the regular MIPS
ISA and the microMIPS ISA are a part of the same ABI as far as the choice
of the dynamic loader is concerned? Or do you maintain that it's merely
up to the installer of every individual system to match the ISA of ld.so
to one supported on given hardware, observing that no single choice can
serve all systems (and therefore in some configurations the filesystem
cannot be shared and a copy will have to be made only to hold a different
ld.so binary)?
Maciej