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

Daniel Jacobowitz
2001-11-25T07:01:44Z

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