[PATCH 4/4] Don't throw an error in 'info registers' for unavailable MIPS GP registers.

[Maciej W. Rozycki]

On Thu, 27 Apr 2017, Pedro Alves wrote:

> > The use of angle brackets with the latter variant is consistent with other 
> > targets, so I might have just a slight preference for it, but I'll be 
> > happy to accept input from other people.
> 
> FWIW, I'd find using anything but <unavailable> when that's what
> GDB means to be making the port be gratuitously different.
> "<unavailable>" always means the same thing in gdb -- gdb knows
> the value materially exists, but it can't get at it for some
> reason (e.g., ptrace does not expose it, a core dump is trimmed, value
> not collect in a trace frame, etc.).

 If you think keeping the word the same across ports is essential, then 
`<unavl>' would be my second choice, at some aesthetical cost.

> Also, I'm not absolutely sure I'm following the code correctly, but ISTM
> that the current mips table printing code can already print strings larger
> than unavailable, like "<invalid float>" in mips_print_fp_register?

 For obvious reasons FP registers are formatted differently:

(gdb) info all-registers
          zero       at       v0       v1       a0       a1       a2       a3
 R0   00000000 fffffff8 77fde8cc 00000000 77ff0000 77fec458 7ffffbd4 7ffffbdc
            t0       t1       t2       t3       t4       t5       t6       t7
 R8   c34e4bff ea5f612e 81010100 2f2f2f2f 7ffffce1 ffffffff f0000000 7ffff4e8
            s0       s1       s2       s3       s4       s5       s6       s7
 R16  78007010 00401360 0051e008 00516188 005161c8 004f0000 00000063 0000006c
            t8       t9       k0       k1       gp       sp       s8       ra
 R24  77fdf64c 00401360 7ffff67c 00000000 78007010 7ffffbd0 00000061 77fcc97c
        status       lo       hi badvaddr    cause       pc
      0100a413 008cbcee 00000006 77f83e90 00800024 00401360
 f0:  0x7ff80000 flt: nan               dbl: nan
 f1:  0x7ff80000 flt: nan
 f2:  0x7ff80000 flt: nan               dbl: nan
 f3:  0x7ff80000 flt: nan
 f4:  0x7ff80000 flt: nan               dbl: nan
 f5:  0x7ff80000 flt: nan
 f6:  0x7ff80000 flt: nan               dbl: nan
 f7:  0x7ff80000 flt: nan
 f8:  0x7ff80000 flt: nan               dbl: nan
 f9:  0x7ff80000 flt: nan
 f10: 0x7ff80000 flt: nan               dbl: nan
 f11: 0x7ff80000 flt: nan
 f12: 0x7ff80000 flt: nan               dbl: nan
 f13: 0x7ff80000 flt: nan
 f14: 0x7ff80000 flt: nan               dbl: nan
 f15: 0x7ff80000 flt: nan
 f16: 0x7ff80000 flt: nan               dbl: nan
 f17: 0x7ff80000 flt: nan
 f18: 0x7ff80000 flt: nan               dbl: nan
 f19: 0x7ff80000 flt: nan
 f20: 0x7ff80000 flt: nan               dbl: nan
 f21: 0x7ff80000 flt: nan
 f22: 0x7ff80000 flt: nan               dbl: nan
 f23: 0x7ff80000 flt: nan
 f24: 0x7ff80000 flt: nan               dbl: nan
 f25: 0x7ff80000 flt: nan
 f26: 0x7ff80000 flt: nan               dbl: nan
 f27: 0x7ff80000 flt: nan
 f28: 0x7ff80000 flt: nan               dbl: nan
 f29: 0x7ff80000 flt: nan
 f30: 0x7ff80000 flt: nan               dbl: nan
 f31: 0x7ff80000 flt: nan
          fcsr      fir  restart
      00000000 00f30000 00000000
(gdb) 

so there's enough space for unusual interpretations.

> I also noticed that there's code in print_gp_register_row that handles
> printing large registers separately:
> 
>       if (mips_float_register_p (gdbarch, regnum))
> 	break;			/* End the row: reached FP register.  */
>       /* Large registers are handled separately.  */
>       if (register_size (gdbarch, regnum) > mips_abi_regsize (gdbarch))
> 	{
> ...
> 	  /* Print this register on a row by itself.  */
> 
> supposedly to avoid column misalignment.  Maybe <unavailable> registers could
> be printed on a row by themselves too?

 Hmm, I've investigated the origin of this piece and it has turned out to 
be quite recent in MIPS port's history, introduced as a hack with commit 
0cc93a06b3ed ("Avoid MIPS port breakage on large registers"), 
<https://sourceware.org/ml/gdb-patches/2007-05/msg00334.html>, to handle 
the artificial $restart register, which is always printed last (and as 
such doesn't break output formatting in a considerable way).

 See the justification downthread and TBH I wouldn't let this change in if 
I were asked to approve it today.  Instead I would request to implement it 
like I did for $fcsr and $fir with commit 78b86327b530 ("mips-tdep: Make 
FCRs always 32-bit") -- though there's something fishy going on there 
anyway as we (still) do not have proper support in place for a debug 
scenario where the ptrace(2) caller has been built for an ABI different 
from the debuggee's ABI -- and the problem is on the kernel side.  Though 
by choosing the ptrace(2) syscall number matching the debuggee's ABI 
(there's one for each) I think it would be avoided; but then there's no 
libc support for doing that.

 So this is not a path I want to follow; I'd rather drop this piece of 
code and handle the case of $restart correctly.

> Note that while the mips table format is more compact, the generic
> format has the advantage that is prints symbol information, like:
> 
> >> rip            0xffffffff8058bb12       0xffffffff8058bb12 <sched_switch+1218>

 With 32 GPRs + HI/LO + PC (which are the minimum subset of architectural 
registers available to user mode software) that does not fit in a standard 
80x24 terminal and IMHO overwhelms the reader with a flood of information 
-- which I believe is also the reason why FPRs are not shown by default.

> (Maybe the ideal would be if the generic code learned about MIPS compact
> format and users could pick the format they want with a format switch
> like "info register /c" or some such.  But again, that'd be a larger
> change which I'd not like to require.)

 That sounds to me like an idea worth considering, assuming that the 
current target-specific defaults are retained.

  Maciej