Maciej W. Rozycki [off-list ref] 于2021年2月20日周六 下午10:55写道：

On Sat, 20 Feb 2021, YunQiang Su wrote:

quoted

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;

Yes. It is some like a workaround.
Should we add a new CONFIG option?

R6 has the value of FR hardwired according to the FPU configuration[1][2].

quoted

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.

The above 2 merge request of golang are just for it.
This patch for kernel is to support the current exists binary that we
cannot modify.
For example, use the kernel of Debian 11 with the userland of Debian 10.

Without this workaround, then, we cannot switch on O32_FP64 support.
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=962485

 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.

Yes. This is a problem that I will inveset.

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

--
YunQiang Su