On Sat, 20 Feb 2021, YunQiang Su wrote:

some binary, for example the output of golang, may be mark as FPXX,
while in fact they are still FP32.

Since FPXX binary can work with both FR=1 and FR=0, we force it to
use FR=0 here.

 This defeats the purpose of FPXX of working with what hardware provides; 
R6 has the value of FR hardwired according to the FPU configuration[1][2].

https://go-review.googlesource.com/c/go/+/239217
https://go-review.googlesource.com/c/go/+/237058

 You need to fix the compiler.  In the interim you may be able to use 
`objcopy', `elfedit' or a similar tool to fix up the broken existing 
binaries if required.

 NB I suspect there is something wrong with the linker as well, because I 
would expect the FP mode of an input legacy object (that is one without 
GNU attributes or MIPS abiflags) to be interpreted according to the legacy 
ABI requirements, i.e. o32 => FR=0, n32/n64 => FR=1, and the output GNU 
attributes or MIPS abiflags set accordingly.  You need to investigate 
further what is going on here.

References:

[1] "MIPS Architecture For Programmers, Volume I-A: Introduction to the 
    MIPS64 Architecture", Imagination Technologies Ltd., Document Number: 
    MD00083, Revision 6.01, August 20, 2014, Table 6.4 "FPU Register 
    Models Availability and Compliance", p. 87

[2] "MIPSAR Architecture For Programmers Volume III: MIPS64 / microMIPS64
    Privileged Resource Architecture", Imagination Technologies Ltd., 
    Document Number: MD00091, Revision 6.03, December 22, 2015, Table 9.49 
    "Status Register Field Descriptions", p. 215

  Maciej