This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
RE: [PATCH 6/13] mips musl support
- From: Matthew Fortune <Matthew dot Fortune at imgtec dot com>
- To: Rich Felker <dalias at libc dot org>
- Cc: Szabolcs Nagy <szabolcs dot nagy at arm dot com>, Gregor Richards <gregor dot richards at uwaterloo dot ca>, Szabolcs Nagy <nsz at port70 dot net>, "gcc-patches at gcc dot gnu dot org" <gcc-patches at gcc dot gnu dot org>
- Date: Tue, 21 Apr 2015 14:59:59 +0000
- Subject: RE: [PATCH 6/13] mips musl support
- Authentication-results: sourceware.org; auth=none
- References: <55354A4A dot 4060702 at arm dot com> <55354B79 dot 3050201 at arm dot com> <6D39441BF12EF246A7ABCE6654B023532103AB78 at LEMAIL01 dot le dot imgtec dot org> <20150421144240 dot GU6817 at brightrain dot aerifal dot cx>
Rich Felker <dalias@libc.org> writes:
> On Tue, Apr 21, 2015 at 01:58:02PM +0000, Matthew Fortune wrote:
> > Szabolcs Nagy <szabolcs.nagy@arm.com> writes:
> > > Set up dynamic linker name for mips.
> > >
> > > gcc/Changelog:
> > >
> > > 2015-04-16 Gregor Richards <gregor.richards@uwaterloo.ca>
> > >
> > > * config/mips/linux.h (MUSL_DYNAMIC_LINKER): Define.
> >
> > I understand that mips musl is o32 only currently is that correct?
>
> This is correct. Other ABIs if/when we support them will have different
> names.
>
> > There does however appear to be both soft and hard float variants
> > listed in the musl docs. Do you plan on using the same dynamic linker
> > name for both float variants? No problem if so but someone must have
> > decided to have unique names for big and little endian so I thought
> it
> > worth checking.
>
> No, it's supposed to be different (-sf suffix for soft float; see
> arch/mips/reloc.h in musl source). If this didn't make it into the
> patches it's an omission, probably because we didn't officially support
> the sf ABI at all for a long time.
>
> > Also, are you aware of the two nan encoding formats that MIPS has and
> > the support present in glibc's dynamic linker to deal with it?
>
> I am aware but somewhat skeptical of treating it as yet another
> dimension to ABI and the resulting ABI combinatorics. The vast majority
> of programs couldn't care less which is which and whether a NAN is
> quiet or signaling. Officially we just use the classic mips ABI (with
> qnan/snan swapped vs other archs) but there's no harm in somebody doing
> the opposite if they really know what they're doing.
Couldn't agree more here but I know some people have been concerned about
it so the strict rules were put in place. I will attempt to remember and
copy the musl list when putting out a plan for formally relaxing the nan
encoding rules. The proposal is probably less than 2 weeks away from being
ready to review, it does of course make certain assumptions originating
from glibc as reference but is an independent ABI proposal.
> > I wonder if it would be wise to refuse to target musl unless the ABI
> > is known to be supported so that we can avoid compatibility issues
> > when different ABI variants are added in musl.
>
> Possibly, though this might make bootstrapping new ABIs harder.
Indeed. The other alternative would be to set the dynamic linker name
to something slightly silly for unsupported ABIs like /lib/fixme.so
which would make it possible to bootstrap via the addition of a symlink
but it is clearly not the approved name.
thanks,
Matthew