Re: [PATCH v9] MIPS: force use FR=0 for FPXX binaries

[YunQiang Su <wzssyqa@gmail.com>]

YunQiang Su <wzssyqa@gmail.com> 于2021年3月29日周一 下午1:09写道：
>
> YunQiang Su <yunqiang.su@cipunited.com> 于2021年3月22日周一 上午10:00写道：
> >
> > The MIPS FPU may have 3 mode:
> >   FR=0: MIPS I style, all of the FPR are single.
> >   FR=1: all 32 FPR can be double.
> >   FRE: redirecting the rw of odd-FPR to the upper 32bit of even-double FPR.
> >
> > The binary may have 3 mode:
> >   FP32: can only work with FR=0 and FRE mode
> >   FPXX: can work with all of FR=0/FR=1/FRE 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. It is caused by the bug of design and linker:
> >   Object produced by pure Go has no FP annotation while in fact they are FP32;
> >   if we link them with the C module which marked as FPXX,
> >   the result will be marked as FPXX. If these fake-FPXX binaries is executed
> >   in FR=1 mode, some problem will happen.
> >
> > In Golang, now we add the FP32 annotation, so the future golang programs
> > won't have this problem. While for the existing binaries, we need a
> > kernel workaround.
> >
>
> We meet a new problem in Debian: with the O32_FP64 enabled kernel,
> mips64el may also be affected.
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=983583
>

Sorry, it is not about O32_FP64, it is about memory segment.
Loongson 3A2000+ supports RI/XI, which stop the access of some memory region.

The problem is about Go itself: why it map the datafile writeonly.

>
>
> > Currently, FR=1 mode is used for all FPXX binary if O32_FP64 supported is enabled,
> > 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.
> >
> > Reference:
> >
> > https://web.archive.org/web/20180828210612/https://dmz-portal.mips.com/wiki/MIPS_O32_ABI_-_FR0_and_FR1_Interlinking
> >
> > https://go-review.googlesource.com/c/go/+/239217
> > https://go-review.googlesource.com/c/go/+/237058
> >
> > Signed-off-by: YunQiang Su <yunqiang.su@cipunited.com>
> > Cc: stable@vger.kernel.org # 4.19+
> > ---
> > v7->v8->v9:
> >         Rollback to use FR=1 for FPXX on R6 CPU.
> >
> > v6->v7:
> >         Use FRE mode for pre-R6 binaries on R6 CPU.
> >
> > v5->v6:
> >         Rollback to V3, aka remove config option.
> >
> > v4->v5:
> >         Fix CONFIG_MIPS_O32_FPXX_USE_FR0 usage: if -> ifdef
> >
> > v3->v4:
> >         introduce a config option: CONFIG_MIPS_O32_FPXX_USE_FR0
> >
> > v2->v3:
> >         commit message: add Signed-off-by and Cc to stable.
> >
> > v1->v2:
> >         Fix bad commit message: in fact, we are switching to FR=0
> >
> >
> >  arch/mips/kernel/elf.c | 20 +++++++++++++-------
> >  1 file changed, 13 insertions(+), 7 deletions(-)
> >
> > diff --git a/arch/mips/kernel/elf.c b/arch/mips/kernel/elf.c
> > index 7b045d2a0b51..554561d5c1f8 100644
> > --- a/arch/mips/kernel/elf.c
> > +++ b/arch/mips/kernel/elf.c
> > @@ -232,11 +232,16 @@ int arch_check_elf(void *_ehdr, bool has_interpreter, void *_interp_ehdr,
> >          *   that inherently require the hybrid FP mode.
> >          * - If FR1 and FRDEFAULT is true, that means we hit the any-abi or
> >          *   fpxx case. This is because, in any-ABI (or no-ABI) we have no FPU
> > -        *   instructions so we don't care about the mode. We will simply use
> > -        *   the one preferred by the hardware. In fpxx case, that ABI can
> > -        *   handle both FR=1 and FR=0, so, again, we simply choose the one
> > -        *   preferred by the hardware. Next, if we only use single-precision
> > -        *   FPU instructions, and the default ABI FPU mode is not good
> > +        *   instructions so we don't care about the mode.
> > +        *   In fpxx case, that ABI can handle all of FR=1/FR=0/FRE mode.
> > +        *   Here, we need to use FR=0 mode instead of FR=1, because some binaries
> > +        *   may be mark as FPXX by mistake due to bugs of design and linker:
> > +        *      The object produced by pure Go has no FP annotation,
> > +        *      then is treated as any-ABI by linker, although in fact they are FP32;
> > +        *      if any-ABI object is linked with FPXX object, the result will be mark as FPXX.
> > +        *      Then the problem happens: run FP32 binaries in FR=1 mode.
> > +        * - If we only use single-precision FPU instructions,
> > +        *   and the default ABI FPU mode is not good
> >          *   (ie single + any ABI combination), we set again the FPU mode to the
> >          *   one is preferred by the hardware. Next, if we know that the code
> >          *   will only use single-precision instructions, shown by single being
> > @@ -248,8 +253,9 @@ int arch_check_elf(void *_ehdr, bool has_interpreter, void *_interp_ehdr,
> >          */
> >         if (prog_req.fre && !prog_req.frdefault && !prog_req.fr1)
> >                 state->overall_fp_mode = FP_FRE;
> > -       else if ((prog_req.fr1 && prog_req.frdefault) ||
> > -                (prog_req.single && !prog_req.frdefault))
> > +       else if (prog_req.fr1 && prog_req.frdefault)
> > +               state->overall_fp_mode = cpu_has_mips_r6 ? FP_FR1 : FP_FR0;
> > +       else if (prog_req.single && !prog_req.frdefault)
> >                 /* Make sure 64-bit MIPS III/IV/64R1 will not pick FR1 */
> >                 state->overall_fp_mode = ((raw_current_cpu_data.fpu_id & MIPS_FPIR_F64) &&
> >                                           cpu_has_mips_r2_r6) ?
> > --
> > 2.20.1
> >
>
>
> --
> YunQiang Su



-- 
YunQiang Su