1. 24 1月, 2016 1 次提交
    • M
      MIPS: math-emu: Correctly handle NOP emulation · e4553573
      Maciej W. Rozycki 提交于
      Fix an issue introduced with commit 9ab4471c ("MIPS: math-emu:
      Correct delay-slot exception propagation") where the emulation of a NOP
      instruction signals the need to terminate the emulation loop.  This in
      turn, if the PC has not changed from the entry to the loop, will cause
      the kernel to terminate the program with SIGILL.
      
      Consider this program:
      
      static double div(double d)
      {
      	do
      		d /= 2.0;
      	while (d > .5);
      	return d;
      }
      
      int main(int argc, char **argv)
      {
      	return div(argc);
      }
      
      which gets compiled to the following binary code:
      
      00400490 <main>:
        400490:	44840000 	mtc1	a0,$f0
        400494:	3c020040 	lui	v0,0x40
        400498:	d44207f8 	ldc1	$f2,2040(v0)
        40049c:	46800021 	cvt.d.w	$f0,$f0
        4004a0:	46220002 	mul.d	$f0,$f0,$f2
        4004a4:	4620103c 	c.lt.d	$f2,$f0
        4004a8:	4501fffd 	bc1t	4004a0 <main+0x10>
        4004ac:	00000000 	nop
        4004b0:	4620000d 	trunc.w.d	$f0,$f0
        4004b4:	03e00008 	jr	ra
        4004b8:	44020000 	mfc1	v0,$f0
        4004bc:	00000000 	nop
      
      Where the FPU emulator is used, depending on the number of command-line
      arguments this code will either run to completion or terminate with
      SIGILL.
      
      If no arguments are specified, then BC1T will not be taken, NOP will not
      be emulated and code will complete successfully.
      
      If one argument is specified, then BC1T will be taken once and NOP will
      be emulated.  At this point the entry PC value will be 0x400498 and the
      new PC value, set by `mips_dsemul' will be 0x4004a0, the target of BC1T.
      The emulation loop will terminate, but SIGILL will not be issued,
      because the PC has changed.  The FPU emulator will be entered again and
      on the second execution BC1T will not be taken, NOP will not be emulated
      and code will complete successfully.
      
      If two or more arguments are specified, then the first execution of BC1T
      will proceed as above.  Upon reentering the FPU emulator the emulation
      loop will continue to BC1T, at which point the branch will be taken and
      NOP emulated again.  At this point however the entry PC value will be
      0x4004a0, the same as the target of BC1T.  This will make the emulator
      conclude that execution has not advanced and therefore an unsupported
      FPU instruction has been encountered, and SIGILL will be sent to the
      process.
      
      Fix the problem by extending the internal API of `mips_dsemul', making
      it return -1 if no delay slot emulation frame has been made, the
      instruction has been handled and execution of the emulation loop needs
      to continue as if nothing happened.  Remove code from `mips_dsemul' to
      reproduce steps made by the emulation loop at the conclusion of each
      iteration, as those will be reached normally now.  Adjust call sites
      accordingly.  Document the API.
      Signed-off-by: NMaciej W. Rozycki <macro@imgtec.com>
      Cc: Aurelien Jarno <aurelien@aurel32.net>
      Cc: linux-mips@linux-mips.org
      Patchwork: https://patchwork.linux-mips.org/patch/12172/Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
      e4553573
  2. 03 9月, 2015 12 次提交
  3. 09 7月, 2015 2 次提交
  4. 13 5月, 2015 1 次提交
  5. 08 4月, 2015 9 次提交
  6. 17 2月, 2015 13 次提交
  7. 24 11月, 2014 1 次提交
    • P
      MIPS: Support for hybrid FPRs · 4227a2d4
      Paul Burton 提交于
      Hybrid FPRs is a scheme where scalar FP registers are 64b wide, but
      accesses to odd indexed single registers use bits 63:32 of the
      preceeding even indexed 64b register. In this mode all FP code
      except that built for the plain FP64 ABI can execute correctly. Most
      notably a combination of FP64A & FP32 code can execute correctly,
      allowing for existing FP32 binaries to be linked with new FP64A binaries
      that can make use of 64 bit FP & MSA.
      
      Hybrid FPRs are implemented by setting both the FR & FRE bits, trapping
      & emulating single precision FP instructions (via Reserved Instruction
      exceptions) whilst allowing others to execute natively. It therefore has
      a penalty in terms of execution speed, and should only be used when no
      fully native mode can be. As more binaries are recompiled to use either
      the FPXX or FP64(A) ABIs, the need for hybrid FPRs should diminish.
      However in the short to mid term it allows for a gradual transition
      towards that world, rather than a complete ABI break which is not
      feasible for some users & not desirable for many.
      
      A task will be executed using the hybrid FPR scheme when its
      TIF_HYBRID_FPREGS flag is set & TIF_32BIT_FPREGS is clear. A further
      patch will set the flags as necessary, this patch simply adds the
      infrastructure necessary for the hybrid FPR mode to work.
      Signed-off-by: NPaul Burton <paul.burton@imgtec.com>
      Cc: linux-mips@linux-mips.org
      Cc: Alexander Viro <viro@zeniv.linux.org.uk>
      Cc: linux-fsdevel@vger.kernel.org
      Cc: linux-kernel@vger.kernel.org
      Patchwork: https://patchwork.linux-mips.org/patch/7683/Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
      4227a2d4
  8. 07 11月, 2014 1 次提交
    • M
      MIPS: Fix build with binutils 2.24.51+ · 842dfc11
      Manuel Lauss 提交于
      Starting with version 2.24.51.20140728 MIPS binutils complain loudly
      about mixing soft-float and hard-float object files, leading to this
      build failure since GCC is invoked with "-msoft-float" on MIPS:
      
      {standard input}: Warning: .gnu_attribute 4,3 requires `softfloat'
        LD      arch/mips/alchemy/common/built-in.o
      mipsel-softfloat-linux-gnu-ld: Warning: arch/mips/alchemy/common/built-in.o
       uses -msoft-float (set by arch/mips/alchemy/common/prom.o),
       arch/mips/alchemy/common/sleeper.o uses -mhard-float
      
      To fix this, we detect if GAS is new enough to support "-msoft-float" command
      option, and if it does, we can let GCC pass it to GAS;  but then we also need
      to sprinkle the files which make use of floating point registers with the
      necessary ".set hardfloat" directives.
      Signed-off-by: NManuel Lauss <manuel.lauss@gmail.com>
      Cc: Linux-MIPS <linux-mips@linux-mips.org>
      Cc: Matthew Fortune <Matthew.Fortune@imgtec.com>
      Cc: Markos Chandras <Markos.Chandras@imgtec.com>
      Cc: Maciej W. Rozycki <macro@linux-mips.org>
      Patchwork: https://patchwork.linux-mips.org/patch/8355/Signed-off-by: NRalf Baechle <ralf@linux-mips.org>
      842dfc11