Re: register_offset_hack() vs REGISTER_BYTE()

[Kevin Buettner <kevinb@redhat.com>]

On May 1,  8:58pm, Andrew Cagney wrote:

> > I'm seeing the following internal error:
> > 
> >     .../frame.c:591: internal-error: Failed to compute the register number
> >     corresponding to 0x296
> > 
> > This is happening because the *addrp value in the following loop (which
> > is in frame_register() in frame.c)...
> > 
> >           for (regnum = 0; regnum < NUM_REGS + NUM_PSEUDO_REGS; regnum++)
> >             {
> >               if (*addrp == register_offset_hack (current_gdbarch, regnum))
> >                 {
> >                   *realnump = regnum;
> >                   return;
> >                 }
> >             }
> > 
> > ...is set using a value obtained from REGISTER_BYTE().  (See
> > sentinel_frame_prev_register in sentinel-frame.c.)  But the
> > value obtained from register_offset_hack() was computed by using the
> > register's virtual type.
> 
> Er, for a legacy architecture, register_offset_hack(i) (aka 
> current_regcache->descr->register_offset) should be REGISTER_BYTE(i). 
> See init_legacy_regcache_descr.
> 
> Sounds like the MIPS is sneeking past:
> 
>    /* If an old style architecture, fill in the remainder of the
>       register cache descriptor using the register macros.  */
>    if (!gdbarch_pseudo_register_read_p (gdbarch)
>        && !gdbarch_pseudo_register_write_p (gdbarch)
>        && !gdbarch_register_type_p (gdbarch))
>      {
>        descr->legacy_p = 1;
>        init_legacy_regcache_descr (gdbarch, descr);
>        return descr;
>      }

Hmm, yes.  I just added some pseudo registers...

Kevin