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

[Pedro Alves <palves at redhat dot com>]

On 04/27/2017 08:37 PM, Maciej W. Rozycki wrote:
> 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.

I'm not sure that trying to come up with short
variants of these special values manually is the best option.

Another output you could see here is "<not saved>".
GDB prints that if GDB figures out the register is not saved
in a frame (or if the DWARF indicates that, via DW_CFA_undefined).

E.g., with the gdb.mi/mi-reg-undefined.exp testcase binary:

(gdb) b stop_frame
Breakpoint 1 at 0x40059a: file mi-reg-undefined.c, line 21.
(gdb) r
Breakpoint 1, stop_frame () at mi-reg-undefined.c:21
(gdb) up
#1  0x00000000004005aa in first_frame () at mi-reg-undefined.c:26
26      in mi-reg-undefined.c
(gdb) info registers
rax            <not saved>
...

We don't have any arch-independent test for this unfortunately.

Maybe a two-pass approach where the first pass prints
each register to a buffer to find the largest width, and then
use that for column width would be more future proof.  It's also
work better if these magic values are ever translated (i18n).

But TBC, I won't object whatever output you decide is best for MIPS,
and I certainly don't want to impose extra work on John -- getting rid
of that error call is the most important here.
I'm just trying to expose a concern so you can have a more
informed decision.

> 
>> 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:

OK.  It wasn't actually obvious to me that each FP register was getting
its own column.

>>       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 

I like how 10 years ago is considered recent.  :-)

Thanks,
Pedro Alves