register_offset_hack() vs REGISTER_BYTE()

[Kevin Buettner <kevinb@redhat.com>]

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.  For this particular architecture (64-bit MIPS),
there are some registers whose virtual size is 4, but which are stored
in an 8-byte container.  Hence the discrepancy.

It's not clear to me that the values being returned by register_offset_hack()
are all that useful.  These are offsets which would occur if you squeezed
all of the "unused" space out of the registers array.

IMO, the call to register_offset_hack() should be replaced with a call
to REGISTER_BYTE().

Opinions?

Kevin