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

[Jakub Jelinek <jakub@redhat.com>]

On Sun, Nov 25, 2001 at 02:01:47AM -0500, Daniel Jacobowitz wrote:
> 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.

I was fixing what I saw (and the next thing I got hit was a ld bug that
cleared some .stab values in shared libs, so I had to recompile all shared
libs).

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

The code in sparc-nat.c is not able to do 64bit userland.
Solaris I believe uses completely different code, SunOS cannot go 64bit and
for Linux it would have to use PT_GETREGS64 and the like.
Actually, Dave Miller and myself used to have a patch for this which made
gdb work at least a little bit with 64bit binaries, but it was not combo
32/64bit gdb which would require far more work (with most complicated stuff
like solib.c for 32bit and 64bit in the same binary).

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

I don't understand how regcache_collect would help here, since the assertion
REGISTER_RAW_SIZE() == 4 would stay. That's just trading a dereference with
a memcpy to an int variable.

	Jakub