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

[John Baldwin]

On Saturday, April 15, 2017 05:02:23 PM Maciej W. Rozycki wrote:
> On Fri, 14 Apr 2017, John Baldwin wrote:
> 
> > > What is the output you're getting in this case?
> > 
> > On FreeBSD (which doesn't support fir) I now get this:
> 
>  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;
        }

      ...
    }
  ...
}

Thus, any target description that doesn't include fir is rejected.  I will
change FreeBSD to export fir via ptrace() and core dumps at some point,
but it doesn't currently.

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);
}

> > It was more dire on a target that doesn't supply all registers.  For example,
> > I have an out of tree target for FreeBSD kernels and stopped threads in
> > FreeBSD's kernel only supply a subset of GPRs.  Without the patch examining
> > registers for a stopped thread looks like this:
> 
>  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.

-- 
John Baldwin