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

["Maciej W. Rozycki" <macro@imgtec.com>]

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.

> Note that Linux doesn't supply a valid fir from core dumps either (it just
> hardcodes it as zero):
> 
> linux-mips-tdep.c:
> 
> void
> mips_supply_fpregset (struct regcache *regcache,
>                       const mips_elf_fpregset_t *fpregsetp)
> {
>   ...
>   char zerobuf[MAX_REGISTER_SIZE];
> 
>   memset (zerobuf, 0, MAX_REGISTER_SIZE);
>   ...
> 
>   /* FIXME: how can we supply FCRIR?  The ABI doesn't tell us.  */
>   regcache_raw_supply (regcache,
>                        mips_regnum (gdbarch)->fp_implementation_revision,
>                        zerobuf);
> }

 Ack.

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

 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?

  Maciej