This is the mail archive of the
mailing list for the glibc project.
Re: Multiarch interpreter names for traditional architectures
On Fri, 9 Feb 2018, Maciej W. Rozycki 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).
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.
There's a subjective element there in that it's possible e.g. to build a
program making no use of floating-point that would thus work with both
soft-float and hard-float libc, but we still consider those different ABIs
if the choice affects the function-calling ABI, and for newer
architectures such as RISC-V make sure to use different dynamic linker
names for hard-float and soft-float ABIs.
Joseph S. Myers