This is the mail archive of the
gdb-patches@sourceware.org
mailing list for the GDB project.
Re: [PATCH 4/4] Don't throw an error in 'info registers' for unavailable MIPS GP registers.
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