This is the mail archive of the
mailing list for the glibc project.
Re: Multiarch interpreter names for traditional architectures
- From: Joseph Myers <joseph at codesourcery dot com>
- To: "Maciej W. Rozycki" <macro at mips dot com>
- Cc: <javier--CbphpPOVok9WFxGWvC7CbkqlsxDZyT at jasp dot net>, <libc-alpha at sourceware dot org>, Javier Serrano Polo <jasp-outbox at ono dot com>
- Date: Fri, 9 Feb 2018 17:34:38 +0000
- Subject: Re: Multiarch interpreter names for traditional architectures
- Authentication-results: sourceware.org; auth=none
- References: <firstname.lastname@example.org> <alpine.DEB.email@example.com> <alpine.DEB.firstname.lastname@example.org>
On Fri, 9 Feb 2018, Maciej W. Rozycki wrote:
> On Mon, 5 Feb 2018, Joseph Myers wrote:
> > > mips,classic NaN,o32,BE ld-linux-mips.so.1
> > > mips,classic NaN,o32,LE ld-linux-mipsle.so.1
> > > mips,classic NaN,n64,LE ld-linux-mips64le.so.1
> > Under-specified, since you have hard-float and soft-float.
> And also MIPS16 and microMIPS, R6 (with its own microMIPS variant), 2008
> NaN, never mind n32.
I didn't think MIPS16 and microMIPS meant different ABIs; I thought a
MIPS16 binary could use either MIPS16 or non-MIPS16 libc, etc.
R6 is indeed a tricky case for defining what is or is not a different ABI
- does removing instructions make something a different ABI? Or if it's
the same ABI, it illustrates (as with powerpc soft-float / SPE) how
distributions may wish to build for different variants that have the same
ABI, and so you necessarily have multiarch directory variants that share
an ABI and thus share a dynamic linker name even if every different ABI
has a different dynamic linker name.
Joseph S. Myers