Rich Felker <dal...@libc.org> writes: > On Tue, Apr 21, 2015 at 01:58:02PM +0000, Matthew Fortune wrote: > > Szabolcs Nagy <szabolcs.n...@arm.com> writes: > > > Set up dynamic linker name for mips. > > > > > > gcc/Changelog: > > > > > > 2015-04-16 Gregor Richards <gregor.richa...@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
