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

[John Baldwin <jhb@freebsd.org>]

On Friday, April 28, 2017 09:48:50 AM John Baldwin wrote:
> On Friday, April 28, 2017 02:51:41 PM Pedro Alves wrote:
> > 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).
> 
> Unfortunately, even "<not saved>" is too long for the 8 character field
> for a 32-bit register value.  One perhaps simple option would be to always
> use the same table layout for 32-bit vs 64-bit (4 columns x 11 rows).  It
> would mean doubling the lines that 'info registers' shows on 32-bit MIPS,
> but it would still fit in 24 lines and would probably simplify the
> implementation.
> 
> However, as you note, the primary goal is removing the error(), and I can
> live with any format that is readable.

Any other thoughts on "<absent>" vs "<unavl>" vs always using the 64-bit
table layout vs <insert other option here>?

-- 
John Baldwin