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


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


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