This is the mail archive of the mailing list for the GDB project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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

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

> -      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

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]