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
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)],
> > - ®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.
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