Re: [PATCH] Fix sparc-*-linux register fetching/storing

[Daniel Jacobowitz <drow@mvista.com>]

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)],
> -			  &registers[REGISTER_BYTE (L0_REGNUM)],
> +      CORE_ADDR sp = *(unsigned int *) & registers[REGISTER_BYTE (SP_REGNUM)];
> +      target_read_memory (sp, &registers[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