diff mbox series

[v7] MIPS: force use FR=0 or FRE for FPXX binaries

Message ID 20210303053342.5920-1-syq@debian.org
State New
Headers show
Series [v7] MIPS: force use FR=0 or FRE for FPXX binaries | expand

Commit Message

YunQiang Su March 3, 2021, 5:33 a.m. UTC
From: YunQiang Su <yunqiang.su@cipunited.com>

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.

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 or FRE (for R6 CPU).

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+

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(-)

Comments

Philippe Mathieu-Daudé March 4, 2021, 4:57 p.m. UTC | #1
On Thu, Mar 4, 2021 at 11:06 AM YunQiang Su <syq@debian.org> wrote:
>

> From: YunQiang Su <yunqiang.su@cipunited.com>

>

> 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.

>

> 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 or FRE (for R6 CPU).

>

> 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+


Here goes the '---' git separator:

---

To remove the following notes when applying, not really useful
in the git history.

>

> 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..4d4db619544b 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/FRE 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_FRE : 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

>
diff mbox series

Patch

diff --git a/arch/mips/kernel/elf.c b/arch/mips/kernel/elf.c
index 7b045d2a0b51..4d4db619544b 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/FRE 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_FRE : 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) ?