This is the mail archive of the
mailing list for the GDB project.
Re: Register group proposal
- To: Stephane Carrez <Stephane dot Carrez at france dot sun dot com>
- Subject: Re: Register group proposal
- From: Andrew Cagney <ac131313 at cygnus dot com>
- Date: Wed, 21 Feb 2001 12:32:44 -0500
- Cc: nsd at redhat dot com, gdb at sources dot redhat dot com, fnasser at redhat dot com, insight at sources dot redhat dot com
- References: <200102211100.MAA29081@sunchorus.France.Sun.COM>
> It would be interesting then to take the 'grouping' into account by
> the new/next register API. The current semantics of `to_fetch_registers()'
> when a -1 is passed is to fetch all registers. You can see that as
> a group of all registers. I think it's then necessary to clarify or
> extend this semantics.
(Assuming I understand Nick's proposal correctly) The groupings apply to
a frame, they don't apply to the raw register cache - the two should be
Too follow up an earlier posting, the only interface between frame and
frame registers and the raw register cache (ignoring async) would be
read_rawreg (cache, rawnum, buf);
write_rawreg (cache, rawnum, buf);
where RAWNUM shouldn't be confused with a FRAME's REGNUM.
As for tuning register performance. Think of the raw register cache
just like a CPU cache. If you get a request to fetch register FOO, then
there is likely benefit in also fetching registers adjacent to FOO. If
your target is asynchronous (yes OK and GDB is event driven :-), then it
would also be free to quietly continue to fetch FOO related registers
long after the value for FOO has been supplied.
To give examples:
For Chorus, if you were given a request for what you know is a raw
floating point register then you might implement it using a call to
``floating point registers (ie, f0,...)'' and supply all of them.
For a remote target, remote.c might send down a ``G<base>:<bound>'' to
get a block of bytes from the register buffer (a packet extenstion) OR
it might request one register ``P<num>'' (a packet extension) and get
back a bunch of registers (much like the existing ``T'' reply can do