This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC 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: [PATCH 6/13] mips musl support


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


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