@@ -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 = 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) ?
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 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: 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(-)