This is the mail archive of the
gdb@sources.redhat.com
mailing list for the GDB project.
register_offset_hack() vs REGISTER_BYTE()
- From: Kevin Buettner <kevinb at redhat dot com>
- To: gdb at sources dot redhat dot com
- Date: Thu, 1 May 2003 17:38:24 -0700
- Subject: register_offset_hack() vs REGISTER_BYTE()
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