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

[John Baldwin <jhb@freebsd.org>]

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