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