回复: [PATCH v6] MIPS: force use FR=0 for FPXX binary

[<yunqiang.su@cipunited.com>]

> On Tue, 2 Mar 2021, YunQiang Su wrote:
> 
> > The MIPS FPU may have 2 mode:
> >   FR=0: MIPS I style, odd-FPR can only be single,
> >         and even-FPR can be double.
> 
>  Depending on the ISA level FR=0 may or may not allow single arithmetic
with
> odd-numbered FPRs.  Compare the FP64A ABI.
> 
> >   FR=1: all 32 FPR can be double.
> 
>  I think it's best to describe the FR=0 mode as one where the FP registers
are
> 32-bit and the FR=1 mode as one where the FP registers are 64-bit (this
mode
> is also needed for the paired-single format).  See:
> 
> <https://dmz-portal.mips.com/wiki/MIPS_O32_ABI_-_FR0_and_FR1_Interlin
> king#1._Introduction>
> 

Thank you. I will update it.

> > The binary may have 3 mode:
> >   FP32: can only work with FR=0 mode
> >   FPXX: can work with both FR=0 and FR=1 mode.
> >   FP64: can only work with FR=1 mode
> >
> > Some binary, for example the output of golang, may be mark as FPXX,
> > while in fact they are FP32.
> >
> > Currently, FR=1 mode is used for all FPXX binary, it makes some wrong
> > behivour of the binaries. Since FPXX binary can work with both FR=1
> > and FR=0, we force it to use FR=0.
> 
>  I think you need to document here what we discussed, that is the linker
bug
> exposed in the context of FPXX annotation by legacy modules that lack FP
> mode annotation, which is the underlying problem.

I will do it.

> 
> > v5->v6:
> > 	Rollback to V3, aka remove config option.
> 
>  You can't reuse v3 as it stands because it breaks R6 as we previously
> discussed.  You need to tell R6 and earlier ISAs apart and set the FR bit
> accordingly.
> 

It won't break r6, as all of r6 binary is FP64, and on r6
   `frdefault' is always false, and `fr1' is always true.
It won't trigger this mode switch.

Oh, you are right, there may be a case that to run legacy app on r6 CPU.
For this case, on r6, we need to set the CPU to FRE mode.

>  It would be more proper I suppose if we actually checked at the boot time
> whether the bit is writable, just like we handle NAN2008, but I don't see
it as
> a prerequisite for this workaround since we currently don't do this either
(it
> would also be good to check if the FP emulation code gets the read-only FR
bit
> right for R6 for FPU-less operation).
> 

Check writable is not needed here.

>  Also you need to put the history in the comment section and not the
commit
> description, so that the change can be directly applied and does not have
to
> be hand-edited by the maintainer.  You don't want to overload him with
> mechanical work.
> 

Ok, I will add more comment.

>   Maciej