| Message ID | 553E4A45.1070107@arm.com |
|---|---|
| State | New |
| Headers | show |
On Mon, Apr 27, 2015 at 7:40 AM, Szabolcs Nagy <szabolcs.nagy@arm.com> wrote: > > > On 21/04/15 15:59, Matthew Fortune wrote: >> Rich Felker <dalias@libc.org> writes: >>> On Tue, Apr 21, 2015 at 01:58:02PM +0000, Matthew Fortune wrote: >>>> There does however appear to be both soft and hard float variants > > Patch v2. > > Now all the ABI variants musl plans to support are represented. > > gcc/Changelog: > > 2015-04-27 Gregor Richards <gregor.richards@uwaterloo.ca> > Szabolcs Nagy <szabolcs.nagy@arm.com> > > * config/mips/linux.h (MUSL_DYNAMIC_LINKER32): Define. > (MUSL_DYNAMIC_LINKER64, MUSL_DYNAMIC_LINKERN32): Define. > (GNU_USER_DYNAMIC_LINKERN32): Update. You checked in config/linux.h CHOOSE_DYNAMIC_LINKER change without config/mips/linux.h change. Now linux-mips is broken.
H.J. Lu <hjl.tools@gmail.com> writes: > On Mon, Apr 27, 2015 at 7:40 AM, Szabolcs Nagy <szabolcs.nagy@arm.com> > wrote: > > > > > > On 21/04/15 15:59, Matthew Fortune wrote: > >> Rich Felker <dalias@libc.org> writes: > >>> On Tue, Apr 21, 2015 at 01:58:02PM +0000, Matthew Fortune wrote: > >>>> There does however appear to be both soft and hard float variants > > > > Patch v2. > > > > Now all the ABI variants musl plans to support are represented. > > > > gcc/Changelog: > > > > 2015-04-27 Gregor Richards <gregor.richards@uwaterloo.ca> > > Szabolcs Nagy <szabolcs.nagy@arm.com> > > > > * config/mips/linux.h (MUSL_DYNAMIC_LINKER32): Define. > > (MUSL_DYNAMIC_LINKER64, MUSL_DYNAMIC_LINKERN32): Define. > > (GNU_USER_DYNAMIC_LINKERN32): Update. > > You checked in config/linux.h CHOOSE_DYNAMIC_LINKER change without > config/mips/linux.h change. Now linux-mips is broken. The MIPS patch is OK. I am concerned that you are aiming for one dynamic linker per ABI variant in musl but are not accounting for soft-float up front in n32/n64. There is time to reconsider this before any of this code gets to a versioned GCC release though. I.e. as it stands this patch is not OK for backporting to GCC 5 without further discussion. There is also the perspective that we should be able to aim for an ABI variant agnostic dynamic linker at some point over the next year by working towards a build that truly uses no float and is hence compatible with all the ABI variants. Thanks, Matthew
On 08/05/15 14:56, H.J. Lu wrote: > On Mon, Apr 27, 2015 at 7:40 AM, Szabolcs Nagy <szabolcs.nagy@arm.com> wrote: >> On 21/04/15 15:59, Matthew Fortune wrote: >>> Rich Felker <dalias@libc.org> writes: >>>> On Tue, Apr 21, 2015 at 01:58:02PM +0000, Matthew Fortune wrote: >>>>> There does however appear to be both soft and hard float variants >> >> Patch v2. >> >> Now all the ABI variants musl plans to support are represented. >> >> gcc/Changelog: >> >> 2015-04-27 Gregor Richards <gregor.richards@uwaterloo.ca> >> Szabolcs Nagy <szabolcs.nagy@arm.com> >> >> * config/mips/linux.h (MUSL_DYNAMIC_LINKER32): Define. >> (MUSL_DYNAMIC_LINKER64, MUSL_DYNAMIC_LINKERN32): Define. >> (GNU_USER_DYNAMIC_LINKERN32): Update. > > You checked in config/linux.h CHOOSE_DYNAMIC_LINKER change > without config/mips/linux.h change. Now linux-mips is broken. > sorry, i cannot roll back the change right now or provide fix up patches. i thought i did the tests without the target patches.. but not mips (only mips is affected). while i'm waiting for the ppl with commit rights.. is it better to roll back the commit or do a single line fix to config/mips/linux.h? (the single line fix is to add a "/dev/null" fourth argument to CHOOSE_DYNAMIC_LINKER macro in the definition of GNU_USER_DYNAMIC_LINKERN32 in config/mips/linux.h) i don't know why i got the mail with such a big delay :(
On Fri, May 08, 2015 at 02:25:11PM +0000, Matthew Fortune wrote: > H.J. Lu <hjl.tools@gmail.com> writes: > > On Mon, Apr 27, 2015 at 7:40 AM, Szabolcs Nagy <szabolcs.nagy@arm.com> > > wrote: > > > > > > > > > On 21/04/15 15:59, Matthew Fortune wrote: > > >> Rich Felker <dalias@libc.org> writes: > > >>> On Tue, Apr 21, 2015 at 01:58:02PM +0000, Matthew Fortune wrote: > > >>>> There does however appear to be both soft and hard float variants > > > > > > Patch v2. > > > > > > Now all the ABI variants musl plans to support are represented. > > > > > > gcc/Changelog: > > > > > > 2015-04-27 Gregor Richards <gregor.richards@uwaterloo.ca> > > > Szabolcs Nagy <szabolcs.nagy@arm.com> > > > > > > * config/mips/linux.h (MUSL_DYNAMIC_LINKER32): Define. > > > (MUSL_DYNAMIC_LINKER64, MUSL_DYNAMIC_LINKERN32): Define. > > > (GNU_USER_DYNAMIC_LINKERN32): Update. > > > > You checked in config/linux.h CHOOSE_DYNAMIC_LINKER change without > > config/mips/linux.h change. Now linux-mips is broken. > > The MIPS patch is OK. I am concerned that you are aiming for one > dynamic linker per ABI variant in musl but are not accounting for > soft-float up front in n32/n64. There is time to reconsider this > before any of this code gets to a versioned GCC release though. I'm not aware of whether there are mips64 chips for which softfloat would be desirable, so I don't know if it's an ABI we'll ever have, but I'm not opposed to adding it here just to be safe (in case we need it). > I.e. as it stands this patch is not OK for backporting to GCC 5 > without further discussion. > > There is also the perspective that we should be able to aim for > an ABI variant agnostic dynamic linker at some point over the next > year by working towards a build that truly uses no float and is > hence compatible with all the ABI variants. For musl that's not going to happen. The dynamic linker and shared libc are one file, which therefore has lots of public interfaces that depend on the argument passing ABI. Rich
On 08/05/15 15:25, Matthew Fortune wrote: > H.J. Lu <hjl.tools@gmail.com> writes: >> On Mon, Apr 27, 2015 at 7:40 AM, Szabolcs Nagy <szabolcs.nagy@arm.com> >> wrote: >>> >>> >>> On 21/04/15 15:59, Matthew Fortune wrote: >>>> Rich Felker <dalias@libc.org> writes: >>>>> On Tue, Apr 21, 2015 at 01:58:02PM +0000, Matthew Fortune wrote: >>>>>> There does however appear to be both soft and hard float variants >>> >>> Patch v2. >>> >>> Now all the ABI variants musl plans to support are represented. >>> >>> gcc/Changelog: >>> >>> 2015-04-27 Gregor Richards <gregor.richards@uwaterloo.ca> >>> Szabolcs Nagy <szabolcs.nagy@arm.com> >>> >>> * config/mips/linux.h (MUSL_DYNAMIC_LINKER32): Define. >>> (MUSL_DYNAMIC_LINKER64, MUSL_DYNAMIC_LINKERN32): Define. >>> (GNU_USER_DYNAMIC_LINKERN32): Update. >> >> You checked in config/linux.h CHOOSE_DYNAMIC_LINKER change without >> config/mips/linux.h change. Now linux-mips is broken. > > The MIPS patch is OK. I am concerned that you are aiming for one > dynamic linker per ABI variant in musl but are not accounting for > soft-float up front in n32/n64. There is time to reconsider this > before any of this code gets to a versioned GCC release though. > i thought musl would not want to support soft float variants of those abis, but now i think it does not hurt to add the -sf there too. if you think that's ok, i can now submit the patch with %{msoft-float:-sf} added to all abi variants. > I.e. as it stands this patch is not OK for backporting to GCC 5 > without further discussion. > > There is also the perspective that we should be able to aim for > an ABI variant agnostic dynamic linker at some point over the next > year by working towards a build that truly uses no float and is > hence compatible with all the ABI variants. i'm not sure what you mean by 'a build that truly uses no float' i thought the direction is to have a potentially hard float abi with kernel emulation when the fpu is not present. > > Thanks, > Matthew >
Szabolcs Nagy <szabolcs.nagy@arm.com> writes: > On 08/05/15 15:25, Matthew Fortune wrote: > > H.J. Lu <hjl.tools@gmail.com> writes: > >> On Mon, Apr 27, 2015 at 7:40 AM, Szabolcs Nagy > >> <szabolcs.nagy@arm.com> > >> wrote: > >>> > >>> > >>> On 21/04/15 15:59, Matthew Fortune wrote: > >>>> Rich Felker <dalias@libc.org> writes: > >>>>> On Tue, Apr 21, 2015 at 01:58:02PM +0000, Matthew Fortune wrote: > >>>>>> There does however appear to be both soft and hard float variants > >>> > >>> Patch v2. > >>> > >>> Now all the ABI variants musl plans to support are represented. > >>> > >>> gcc/Changelog: > >>> > >>> 2015-04-27 Gregor Richards <gregor.richards@uwaterloo.ca> > >>> Szabolcs Nagy <szabolcs.nagy@arm.com> > >>> > >>> * config/mips/linux.h (MUSL_DYNAMIC_LINKER32): Define. > >>> (MUSL_DYNAMIC_LINKER64, MUSL_DYNAMIC_LINKERN32): Define. > >>> (GNU_USER_DYNAMIC_LINKERN32): Update. > >> > >> You checked in config/linux.h CHOOSE_DYNAMIC_LINKER change without > >> config/mips/linux.h change. Now linux-mips is broken. > > > > The MIPS patch is OK. I am concerned that you are aiming for one > > dynamic linker per ABI variant in musl but are not accounting for > > soft-float up front in n32/n64. There is time to reconsider this > > before any of this code gets to a versioned GCC release though. > > > > i thought musl would not want to support soft float variants of those > abis, but now i think it does not hurt to add the -sf there too. > > if you think that's ok, i can now submit the patch with %{msoft-float:- > sf} added to all abi variants. That's fine. Go ahead. > > I.e. as it stands this patch is not OK for backporting to GCC 5 > > without further discussion. > > > > There is also the perspective that we should be able to aim for an ABI > > variant agnostic dynamic linker at some point over the next year by > > working towards a build that truly uses no float and is hence > > compatible with all the ABI variants. > > i'm not sure what you mean by 'a build that truly uses no float' > > i thought the direction is to have a potentially hard float abi with > kernel emulation when the fpu is not present. With MIPS having such a rich matrix of ABI variants the need to build code to target all variants is quite costly. We currently have to do this regardless of whether the code in it is affected by the differences. We are looking at ways to create more generic objects so that some libraries can get away with fewer build variations. The major variation for MIPS is the set of floating-point extensions so knowing that a module has no interest in floating point code is quite valuable. Since Rich has just pointed out that the dynamic linker and C library are one and the same for musl then this will not be of as much value to musl. Thanks, Matthew > > > > > Thanks, > > Matthew > >
On Fri, May 08, 2015 at 03:41:31PM +0100, Szabolcs Nagy wrote: > > I.e. as it stands this patch is not OK for backporting to GCC 5 > > without further discussion. > > > > There is also the perspective that we should be able to aim for > > an ABI variant agnostic dynamic linker at some point over the next > > year by working towards a build that truly uses no float and is > > hence compatible with all the ABI variants. > > i'm not sure what you mean by 'a build that truly uses no float' > > i thought the direction is to have a potentially hard float abi > with kernel emulation when the fpu is not present. I think Matthew's idea was that the dynamic linker could be agnostic since it doesn't need floating point arithmetic itself, then load appropriate libraries depending on the ABI of the application (presumably determined by some flags in _DYNAMIC or perhaps the main ELF header). Of course with some familiarity with musl it becomes clear why this is not an option, but to answer things like this we need to think from a standpoint of non-familiarity with musl. :-) Rich
On Fri, 8 May 2015, Rich Felker wrote: > On Fri, May 08, 2015 at 03:41:31PM +0100, Szabolcs Nagy wrote: > > > I.e. as it stands this patch is not OK for backporting to GCC 5 > > > without further discussion. > > > > > > There is also the perspective that we should be able to aim for > > > an ABI variant agnostic dynamic linker at some point over the next > > > year by working towards a build that truly uses no float and is > > > hence compatible with all the ABI variants. > > > > i'm not sure what you mean by 'a build that truly uses no float' > > > > i thought the direction is to have a potentially hard float abi > > with kernel emulation when the fpu is not present. > > I think Matthew's idea was that the dynamic linker could be agnostic > since it doesn't need floating point arithmetic itself, then load Note that however the dynamic linker does properly need to save and restore call-clobbered registers used for argument passing (because of IFUNCs, user-provided malloc, audit hooks etc. that might affect them even if the dynamic linker itself doesn't); see <https://sourceware.org/ml/libc-alpha/2014-01/msg00673.html>. So any floating-point-agnostic dynamic linker would, if fixing the bugs around not saving / restoring such registers, need to have runtime-conditional code to save and restore them rather than simple compile-time conditionals.
On Fri, May 08, 2015 at 04:50:28PM +0000, Joseph Myers wrote: > On Fri, 8 May 2015, Rich Felker wrote: > > > On Fri, May 08, 2015 at 03:41:31PM +0100, Szabolcs Nagy wrote: > > > > I.e. as it stands this patch is not OK for backporting to GCC 5 > > > > without further discussion. > > > > > > > > There is also the perspective that we should be able to aim for > > > > an ABI variant agnostic dynamic linker at some point over the next > > > > year by working towards a build that truly uses no float and is > > > > hence compatible with all the ABI variants. > > > > > > i'm not sure what you mean by 'a build that truly uses no float' > > > > > > i thought the direction is to have a potentially hard float abi > > > with kernel emulation when the fpu is not present. > > > > I think Matthew's idea was that the dynamic linker could be agnostic > > since it doesn't need floating point arithmetic itself, then load > > Note that however the dynamic linker does properly need to save and > restore call-clobbered registers used for argument passing (because of > IFUNCs, user-provided malloc, audit hooks etc. that might affect them even > if the dynamic linker itself doesn't); see > <https://sourceware.org/ml/libc-alpha/2014-01/msg00673.html>. So any > floating-point-agnostic dynamic linker would, if fixing the bugs around > not saving / restoring such registers, need to have runtime-conditional > code to save and restore them rather than simple compile-time > conditionals. FWIW, this also doesn't apply to musl; we don't do lazy binding and there's no resolver function. The dynamic linker never calls into code provided by the application except for executing init/fini functions. IFUNC may be provided at some point but it wouldn't be lazy, so call-clobbered registers aren't relevant; right now the lack of any specification for what an IFUNC callback is permitted to do (in the form of "if you do anything else, the behavior is undefined") is what's blocking support. Rich
On 05/08/2015 08:25 AM, Matthew Fortune wrote: > > There is also the perspective that we should be able to aim for > an ABI variant agnostic dynamic linker at some point over the next > year by working towards a build that truly uses no float and is > hence compatible with all the ABI variants. Having seen the pain around this for ARM up close and personal, if you can see a path to that goal, I'd suggest running as fast as you can to that goal. jeff
On 05/08/2015 10:50 AM, Joseph Myers wrote: > > Note that however the dynamic linker does properly need to save and > restore call-clobbered registers used for argument passing (because of > IFUNCs, user-provided malloc, audit hooks etc. that might affect them even > if the dynamic linker itself doesn't); see > <https://sourceware.org/ml/libc-alpha/2014-01/msg00673.html>. So any > floating-point-agnostic dynamic linker would, if fixing the bugs around > not saving / restoring such registers, need to have runtime-conditional > code to save and restore them rather than simple compile-time > conditionals. Right. So there has to be some reasonable cost way to find out if you have FPU registers at runtime, then select between the code paths at runtime. Jeff
Jeff Law <law@redhat.com> writes: > On 05/08/2015 10:50 AM, Joseph Myers wrote: > > > > Note that however the dynamic linker does properly need to save and > > restore call-clobbered registers used for argument passing (because of > > IFUNCs, user-provided malloc, audit hooks etc. that might affect them > > even if the dynamic linker itself doesn't); see > > <https://sourceware.org/ml/libc-alpha/2014-01/msg00673.html>. So any > > floating-point-agnostic dynamic linker would, if fixing the bugs > > around not saving / restoring such registers, need to have > > runtime-conditional code to save and restore them rather than simple > > compile-time conditionals. > Right. So there has to be some reasonable cost way to find out if you > have FPU registers at runtime, then select between the code paths at > runtime. Indeed and I think there are many ways to achieve that without hardware support as the cost of loading a global variable in the dynamic linker wouldn't be significant. I think MIPS ABIs are the only ones with enough information available at runtime to achieve this currently but the principles should apply to any arch. The work we are investigating as part of PR65862 will help all this as the intention is to avoid FPR usage unless floating point is actually used. There is then some thinking involved in figuring out what no-float should really mean: i.e. no floating point types used, no FPU insns used and/or no floating point in any of the calls/global functions. I haven't spent enough time thinking about which ones are the most important from above yet. Matthew
diff --git a/gcc/config/mips/linux.h b/gcc/config/mips/linux.h index 91df261..6038498 100644 --- a/gcc/config/mips/linux.h +++ b/gcc/config/mips/linux.h @@ -37,7 +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}" +#undef MUSL_DYNAMIC_LINKER32 +#define MUSL_DYNAMIC_LINKER32 "/lib/ld-musl-mips%{EL:el}%{msoft-float:-sf}.so.1" +#undef MUSL_DYNAMIC_LINKER64 +#define MUSL_DYNAMIC_LINKER64 "/lib/ld-musl-mips64%{EL:el}.so.1" +#define MUSL_DYNAMIC_LINKERN32 "/lib/ld-musl-mipsn32%{EL:el}.so.1" + #define BIONIC_DYNAMIC_LINKERN32 "/system/bin/linker32" #define GNU_USER_DYNAMIC_LINKERN32 \ CHOOSE_DYNAMIC_LINKER (GLIBC_DYNAMIC_LINKERN32, UCLIBC_DYNAMIC_LINKERN32, \ - BIONIC_DYNAMIC_LINKERN32) + BIONIC_DYNAMIC_LINKERN32, MUSL_DYNAMIC_LINKERN32)