MIPS: Provide FPU info and decode FCSR in `info float'
authorYao Qi <yao@codesourcery.com>
Thu, 18 Dec 2014 12:47:28 +0000 (20:47 +0800)
committerYao Qi <yao@codesourcery.com>
Thu, 18 Dec 2014 12:47:28 +0000 (20:47 +0800)
commit1bab73830f14fc0dcb1b0e7663cf8c2e02b10d72
treedb401e0223156fae0748887c2b1b6ad6d2bed4ab
parentcc86d1cb9510dbba32bf19e5d2699f2972efbc03
MIPS: Provide FPU info and decode FCSR in `info float'

This patch is the V2.  V1 can be found in
https://sourceware.org/ml/gdb-patches/2012-05/msg00938.html
V2 is to address Joel's comment
<https://sourceware.org/ml/gdb-patches/2012-06/msg00289.html> about
keeping dumping floating point registers.  Additionally, command
'info float' prints bits on nan2008 and abs2008.

------------------------------------------------------------------

 The change below provides a MIPS-specific handler for the:

(gdb) info float

command.  It provides information about the FPU type available (if any),
the FPU register width, and decodes the CP1 Floating Point Control and
Status Register (FCSR):

(gdb) print /x $fsr
$1 = 0xff83ffff
(gdb) info float
fpu type: double-precision
reg size: 32 bits
cond    : 0 1 2 3 4 5 6 7
cause   : inexact uflow oflow div0 inval unimp
mask    : inexact uflow oflow div0 inval
flags   : inexact uflow oflow div0 inval
rounding: -inf
flush   : zero

 One point to note about CP1.FCSR are the non-standard Flush-to-Nearest
and Flush-Override bits.  They are not a part of the MIPS architecture and
take two positions reserved for an implementation-dependent use in the
architecture.  They are present in all the FPU implementations made by
MIPS Technologies since the spin-off from SGI.

 I haven't been able to track down a single other MIPS FPU implementation
that would make any use of these bits and they are required to be
hardwired to zero by the architecture specification if unimplemented.
Therefore I think it makes sense to report them in the current way.

 GDB has no guaranteed access to the CP0 Processor Identification (PRId)
register to validate this feature properly and the ID information stored
in the CP1 Floating Point Implementation Register (FIR) is from my
experience not reliable enough (there's no Company ID available there for
once unlike in CP0.PRId and Processor ID is not guaranteed to be unique).

 As a side note we should probably dump CP1.FIR information as well, as
there's useful stuff indicating some FPU features there.  That's material
for another change however.

gdb/

2014-12-18  Nigel Stephens  <nigel@mips.com>
            Maciej W. Rozycki  <macro@codesourcery.com>

* mips-tdep.c (print_fpu_flags): New function.
(mips_print_float_info): Likewise.
(mips_gdbarch_init): Install mips_print_float_info as gdbarch
print_float_info routine.

gdb/testsuite/

2014-12-18  Nigel Stephens  <nigel@mips.com>
            Maciej W. Rozycki  <macro@codesourcery.com>

* gdb.base/float.exp: Handle the new output from "info float" on
MIPS targets.
gdb/ChangeLog
gdb/mips-tdep.c
gdb/testsuite/ChangeLog
gdb/testsuite/gdb.base/float.exp