gdb/riscv: improve (and fix) display of frm field in 'info registers'

gdb/riscv: improve (and fix) display of frm field in 'info registers'

On RISC-V the FCSR (float control/status register) is split into two
parts, FFLAGS (the flags) and FRM (the rounding mode).  Both of these
two fields are part of the FCSR register, but can also be accessed as
separate registers in their own right.  And so, we have three separate
registers, $fflags, $frm, and $fcsr, with the last of these being the
combination of the first two.

Here's how the bits of FCSR are split between FRM and FFLAGS:

         ,--------- FFLAGS
       |---|
    76543210 <----- FCSR
    |-|
     '--------------FRM

Here's how GDB currently displays these registers:

  (gdb) info registers $fflags $frm $fcsr
  fflags         0x0      RD:0 NV:0 DZ:0 OF:0 UF:0 NX:0
  frm            0x0      FRM:0 [RNE (round to nearest; ties to even)]
  fcsr           0x0      RD:0 NV:0 DZ:0 OF:0 UF:0 NX:0 FRM:0 [RNE (round to nearest; ties to even)]

Notice the 'RD' field which is present in both $fflags and $fcsr.
This field contains the value of the FRM field, which makes sense when
displaying the $fcsr, but makes no sense when displaying $fflags, as
the $fflags doesn't include the FRM field.

Additionally, the $fcsr already includes an FRM field, so the
information in 'RD' is duplicated.  Consider this:

  (gdb) set $frm = 0x3
  (gdb) info registers $fflags $frm $fcsr                             │
  fflags         0x0      RD:0 NV:0 DZ:0 OF:0 UF:0 NX:0
  frm            0x3      FRM:3 [RUP (Round up towards +INF)]
  fcsr           0x60     RD:3 NV:0 DZ:0 OF:0 UF:0 NX:0 FRM:3 [RUP (Round up towards +INF)]

See how the 'RD' field in $fflags still displays 0, while the 'RD' and
'FRM' fields in $fcsr show the same information.

The first change I propose in this commit is to remove the 'RD'
field.  After this change the output now looks like this:

  (gdb) info registers $fflags $frm $fcsr
  fflags         0x0      NV:0 DZ:0 OF:0 UF:0 NX:0
  frm            0x0      FRM:0 [RNE (round to nearest; ties to even)]
  fcsr           0x0      NV:0 DZ:0 OF:0 UF:0 NX:0 FRM:0 [RNE (round to nearest; ties to even)]

Next, I spotted that the text that goes along with the 'FRM' field was
not wrapped in the i18n markers for internationalisation, so I added
those.

Next, I spotted that:

  (gdb) set $frm=0x7
  (gdb) info registers $fflags $frm $fcsr
  fflags         0x0      RD:0 NV:0 DZ:0 OF:0 UF:0 NX:0
  frm            0x7      FRM:3 [RUP (Round up towards +INF)]
  fcsr           0xe0     RD:7 NV:0 DZ:0 OF:0 UF:0 NX:0 FRM:3 [RUP (Round up towards +INF)]

Notice that despite being a 3-bit field, FRM masks to 2-bits.
Checking the manual I can see that the FRM field is 3-bits, and is
defined for all 8 values.  That GDB masks to 2-bits is just a bug I
think, so I've fixed this.

Finally, the 'FRM' text for value 0x7 is wrong.  Currently we use the
text 'dynamic rounding mode' for value 0x7.  However, this is not
really correct.

A RISC-V instruction can either encode the rounding mode within the
instruction, or a RISC-V instruction can choose to use a global,
dynamic rounding mode.

So, for the rounding-mode field of an _instruction_ the value 0x7
indicates "dynamic round mode", the instruction should defer to the
rounding mode held in the FRM field of the $fcsr.

But it makes no sense for the FRM of $fcsr to itself be set to
0x7 (dynamic rounding mode), and indeed, section 11.2, "Floating-Point
Control and Status Register" of the RISC-V manual, says that a value
of 0x7 in the $fcsr FRM field is invalid, and if an instruction has
_its_ round-mode set to dynamic, and the FRM field is also set to 0x7,
then an illegal instruction exception is raised.

And so, I propose changing the text for value 0x7 of the FRM field to
be "INVALID[7] (Dynamic rounding mode)".  We already use the text
"INVALID[5]" and "INVALID[6]" for the two other invalid fields,
however, I think adding the extra "Dynamic round mode" hint might be
helpful.

I've added a new test that uses 'info registers' to check what GDB
prints for the three registers related to this patch.  There is one
slight oddity with this test - for the fflags and frm registers, the
test accepts both the "normal" output (as described above), but also
allows these registers to be reported as '<unavailable>'.

The reason why I accept <unavailable> is that currently, the RISC-V,
native Linux target advertises these registers in its target
description, but then doesn't support reading or writing of these
registers, this results in the registers being reported as
unavailable.

A later patch in this series will address this issue, and will remove
this check for <unavailable>.