This is the mail archive of the gdb-patches@sources.redhat.com 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 Sun, Nov 25, 2001 at 11:32:01AM -0500, Jakub Jelinek wrote:
> 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).

Ugh.  Not my fault, I hope :)

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

Well, regcache_collect is the only approved interface to the contents
of registers[] for one thing.  It would also prevent the need for the
cast (although you'd have to clear the upper half of the variable
first and make sure to stuff it into the low bytes since we're
big-endian.  Ew.).

Andrew?  Do we need to have a regcache_collect_core_addr, to sign
extend and shift appropriately for each architecture?


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