| Message ID | 55354B79.3050201@arm.com |
|---|---|
| State | New |
| Headers | show |
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? 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. 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 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. Thanks, Matthew
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. > 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. Rich
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
diff --git a/gcc/config/mips/linux.h b/gcc/config/mips/linux.h index 91df261..5057bc5 100644 --- a/gcc/config/mips/linux.h +++ b/gcc/config/mips/linux.h @@ -37,6 +37,13 @@ along with GCC; see the file COPYING3. If not see #define UCLIBC_DYNAMIC_LINKERN32 \ "%{mnan=2008:/lib32/ld-uClibc-mipsn8.so.0;:/lib32/ld-uClibc.so.0}" +#if TARGET_ENDIAN_DEFAULT == 0 /* LE */ +#define MUSL_DYNAMIC_LINKER_E "%{EB:;:el}" +#else +#define MUSL_DYNAMIC_LINKER_E "%{EL:el}" +#endif +#define MUSL_DYNAMIC_LINKER "/lib/ld-musl-mips" MUSL_DYNAMIC_LINKER_E ".so.1" + #define BIONIC_DYNAMIC_LINKERN32 "/system/bin/linker32" #define GNU_USER_DYNAMIC_LINKERN32 \ CHOOSE_DYNAMIC_LINKER (GLIBC_DYNAMIC_LINKERN32, UCLIBC_DYNAMIC_LINKERN32, \