[PATCH] Fix sparc-*-linux register fetching/storing
Daniel Jacobowitz
drow@mvista.com
Sat Nov 10 13:03:00 GMT 2001
On Fri, Nov 23, 2001 at 03:42:21PM +0100, Jakub Jelinek wrote:
> Hi!
>
> On sparc-*-linux, bfd automatically supports both 32bit and 64bit ABI and
> thus CORE_ADDR is 64bit type. Unfortunately, this means %l0-%i7 registers
> are read from incorrect place (and stored too), particularly from caller's
> instruction chain. This means even simple commands like next or bt don't
> work at all.
> Ok to commit?
After this patch, Sparc still seems to be a little badly off
(particularly in calling inferior functions), but much better than
before. I'm a little confused about it though; I don't think it's
correct.
> - target_read_memory (*(CORE_ADDR *) & registers[REGISTER_BYTE (SP_REGNUM)],
> - ®isters[REGISTER_BYTE (L0_REGNUM)],
> + CORE_ADDR sp = *(unsigned int *) & registers[REGISTER_BYTE (SP_REGNUM)];
> + target_read_memory (sp, ®isters[REGISTER_BYTE (L0_REGNUM)],
How was this going wrong exactly? We don't have any assurance that I
can think of that the stack will always be under the 32-bit mark in a
true 64-bit userland.
Is the entry in registers[] only four bytes long? If so, it seems that
using regcache_collect here is the way to go. For Sparc, which doesn't
sign-extend the way MIPS does, collecting four bytes out of the
register cache should be fine.
--
Daniel Jacobowitz Carnegie Mellon University
MontaVista Software Debian GNU/Linux Developer
More information about the Gdb-patches
mailing list