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 Saturday, April 15, 2017 11:06:35 PM Maciej W. Rozycki wrote:
> On Sat, 15 Apr 2017, John Baldwin wrote:
>
> > > If the register is not ever supplied, then you need a target description
> > > that does not include it. The rest of code will then handle it correctly.
> >
> > No, mips-tdep.c requires fir to be included in the description:
> >
> > static struct gdbarch *
> > mips_gdbarch_init (struct gdbarch_info info, struct gdbarch_list *arches)
> > {
> > ...
> > /* Check any target description for validity. */
> > if (tdesc_has_registers (info.target_desc))
> > {
> > ...
> > valid_p
> > &= tdesc_numbered_register (feature, tdesc_data,
> > mips_regnum.fp_implementation_revision,
> > "fir");
> >
> > if (!valid_p)
> > {
> > tdesc_data_cleanup (tdesc_data);
> > return NULL;
> > }
> >
> > ...
> > }
> > ...
> > }
>
> That needs to be fixed then. Previously there was no need to handle FIR
> specially. Overall we need to handle configurations without FPU as well.
That might be true, but that is a larger patch (and it doesn't help with my
kernel target case where only a subset of GPRs are valid).
> > > Why can't the remaining general registers be read or written -- is that a
> > > bug in the kernel?
> > >
> > > That sort of defeats the point of debugging, where you'd expect to be
> > > able to poke at any register that is at debuggee's disposal (so not
> > > supplying FIR can be considered a bug too). A program's variable could
> > > live in such an inaccessible register for example.
> >
> > This isn't about the user thread state. When a user thread enters the kernel
> > due to an exception, system call, etc. then all registers are saved and are
> > available to the debugger. This is about debugging kernel threads in the kernel
> > itself. During a context switch, only a subset of registers are explicitly
> > saved in the thread's control block on FreeBSD (generally callee-save registers).
> > Caller-save registers can be found by unwinding the stack.
>
> Fair enough. Such details have to be given in the patch description
> itself though.
Ok. I can give this as an example in the commit log.
> I'm somewhat put off by the truncated message in the 32-bit case though
> -- unless a better proposition comes up, then how about using `xxxxxxxx'
> and `xxxxxxxxxxxxxxxx' for the 32-bit and 64-bit case respectively as with
> some previous effort? What do other target backends do?
I don't disagree with the 32-bit format and am certainly open to other
options. Other architectures don't generally use a table and use the full
"<unavailable>" string, e.g. on a FreeBSD 64-bit x86 kernel (which uses the
"stock" method to print registers rather than a gdbarch-specific one):
(kgdb) info registers
rax <unavailable>
rbx 0xfffff800085cb500 -8795952728832
rcx <unavailable>
rdx <unavailable>
rsi <unavailable>
rdi <unavailable>
rbp 0xfffffe04674819c0 0xfffffe04674819c0
rsp 0xfffffe0467481968 0xfffffe0467481968
r8 <unavailable>
r9 <unavailable>
r10 <unavailable>
r11 <unavailable>
r12 0xffffffff80d43b00 -2133574912
r13 0xfffff801fb2f3000 -8787583881216
r14 0x0 0
r15 0xffffffff80d43b00 -2133574912
rip 0xffffffff8058bb12 0xffffffff8058bb12 <sched_switch+1218>
eflags <unavailable>
cs 0x20 32
ss 0x28 40
ds <unavailable>
es <unavailable>
fs <unavailable>
gs <unavailable>
--
John Baldwin