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

[Daniel Jacobowitz <drow@mvista.com>]

On Mon, Nov 26, 2001 at 03:34:41PM -0500, Andrew Cagney wrote:
> 
> >>That sounds like overkill.  If you need to be doing sign/zero extension 
> >>stuff then I'd be looking at explicit calls to extract_signed_integer() 
> >>and/or extract_unsigned_integer() in the nat code.
> >>
> >>A sequence like:
> >>
> >>void *buf = alloca (MAX_REGISTER_RAW_SIZE);
> >>regcache_collect (my reg, buf);
> >>LONGEST val = extract_unsigned_integer (buf, REGISTER_RAW_SIZE(my reg));
> >>store_unsigned_integer (dest, dest size, val);
> >>
> >>should insulate it from the current problems.
> >
> >
> >But won't we want this absolutely every time we extract a CORE_ADDR? 
> >And for that matter, I'm talking about getting a target memory address
> >out of a register; is store_*signed_integer right for that?  Is there
> >an extract_pointer or so?
> 
> In *-nat.c?  Now I'm confused :-)
> 
> Doesn't the *-nat.c file just copy raw register bytes between the 
> regcache and the /proc or ptrace() interface?  The only complication I 
> could see is if someone used 32 bit ptrace calls to get the values for a 
> regcache that had space for 64 bit registers - the above code snipit 
> would handle that.
> 
> The reason for suggesting extract/store signed/unsigned integer is that 
> they have clear, machine independant, semantics that work on 
> uninterpreted (well apart from assuming they are integers :-) bytes.

Well, remember that we can't cast things to (CORE_ADDR *) reliably. 
With --enable-64-bit-bfd, that has a tendency to turn into a 'long long *'.
What was happening was reading $sp out of the regcache, and then
passing it to target_read_memory.  If this were MIPS, I think we'd have
to sign extend there, for "correctness".  We'd eventually truncate it
back down with a cast in infptrace.c, though.

I just don't like duplicating that above code sequence everywhere we
get a pointer out of a register into a CORE_ADDR.  It seems like a very
frequent operation, in nat or in tdep.

-- 
Daniel Jacobowitz                           Carnegie Mellon University
MontaVista Software                         Debian GNU/Linux Developer