This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]