> > My most recent reason for looking at this is because I am starting to > > understand/look at mips ld.so from glibc and it appears to make such > > an assumption. I.e. I cannot see it using any specific options to > > prevent the use of floating point but the path into the dynamic linker > > for resolving symbols only preserves integer argument registers and > > ignores floating point. I have to therefore assume that the MIPS > > backend manages to avoid what I thought was a common problem of using > > floating point registers as integer scratch in extreme circumstances. > > Even if you avoid use of floating point (via -ffixed-* options - check > carefully > that those are actually effective, as for some targets there are or have been > initialization order issues for registers that are only conditionally > available, > that may make such options ineffective - not -msoft-float, as that would > mark the objects ABI-incompatible), you'd still need to save and restore call- > clobbered registers used for argument passing, because IFUNC resolvers, > audit modules and user implementations of malloc might clobber them.
This is where I was going next with this but I didn't know if it was appropriate to go into such things on the GCC list. > Thus, I think ld.so needs to save and restore those registers (and so there > isn't much point making it avoid floating point). See > <https://sourceware.org/ml/libc-alpha/2014-01/msg00673.html>. Thanks for this and I agree. I've read some of the threads on this topic but not these. I have also realised I've stumbled my way into something that will also affect/be affected by how we define the ABI extension for MSA. If we define an ABI extension that uses MSA registers for arguments then these would also need saving around dynamic loader entry points. I'm still interested in how successfully the MIPS backend is managing to avoid floating point but I am also convinced there are bugs in ld.so entry points for MIPS. Matthew
