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
