This is the mail archive of the
gdb-patches@sources.redhat.com
mailing list for the GDB project.
Re: [PATCH] Fix sparc-*-linux register fetching/storing
- From: Daniel Jacobowitz <drow at mvista dot com>
- To: Jakub Jelinek <jakub at redhat dot com>
- Cc: gdb-patches at sources dot redhat dot com
- Date: Sun, 25 Nov 2001 02:01:47 -0500
- Subject: Re: [PATCH] Fix sparc-*-linux register fetching/storing
- References: <20011123154220.A562@sunsite.ms.mff.cuni.cz>
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