This is the mail archive of the
gdb@sourceware.cygnus.com
mailing list for the GDB project.
Re: Remote protocol extension for register ranges
- To: Fernando Nasser <fnasser at redhat dot com>, "J.T. Conklin" <jtc at redbacknetworks dot com>
- Subject: Re: Remote protocol extension for register ranges
- From: Andrew Cagney <ac131313 at cygnus dot com>
- Date: Thu, 23 Mar 2000 18:42:22 +1100
- CC: gdb at sourceware dot cygnus dot com
- Organization: Cygnus Solutions
- References: <38D8CFA4.C3535C93@redhat.com>
Fernando Nasser wrote:
>
> Presently, the remote protocol can only read all registers of a target.
> This is OK for the context registers (the ones that are saved by the OD
> on a context switch) but this is a serious limitation for machines that
> have lots of additional registers. It is just not feasible to read them
> all at every "g" packet.
>
> I would like to add parameters to the "g" packet. Something similar has
> been proposed before -- the only difference is that I would like the
> parameters to be a register number or a register number range range.
>
> For instance:
>
> g82 Reads register 82
> g31-40 Reads registers 31-40
>
> Gdb would test for the acceptance of these types of packets by the stub
> and fall back to the less efficient form if not (like it does for "P"
> packets).
>
> I really need this feature as do other people that are dealing with one
> of the numerous microprocessors that have too many extra registers. And
> it is becoming quite urgent now.
>
> What is the current thinking about this? Are there other proposals I am
> not aware of? What are the maintainers position?
FYI, I had two potential ideas in mind. Which I prefer depends on the
target I'm hacking on.
1. gG like mM
Treat the target register file like
a separate section of memory.
Without arguments, gG would transfer
the first few registers.
With arguments (offset, length) a
sub section of the register file
could be transfered.
If read section was supported, write
section had to also be supported.
The first obvious optomization
would be to read a packet of registers
when ever a single register was
requested.
The problem is that the data
is very raw. Embedded hardware
stores registers in target byte-ordered
register files. Remote simulators
and ICEs like to handle host
ordered structures. That raw target
offset would have to be maped onto
a sequence of host array elements.
2. like pP
The second option would be to
extend/fix the pP packets (or
a successor) so that they could
take a range of registers
and would use *NETWORK* byte
ordering.
Such a system would be good
for small register transfers
It could certainly be taught
to pull in a range of registers
when only one is asked for.
The target could even be
given that freedom: Register
six please; Certainly, along
with registers 0..5, 7..9.
It would be more natural to
simulators, ICEs and the like
where the raw data tends to
come in host structured chunks.
I guess I could also live with
pP just being extended.
Be wary of ``-''. In some
situtations the stub can parse it
as a negative number.
Refering to follow-on threads^D^D^D^D postings:
I note the gG proposal above is like J.T.s ``Y'' proposal - perhaphs
J.T.s posted his suggestion before and I've just picked it up :-/
W.R.T. detecting support in the ``gG'' packet, provided the fetch works,
the send would have to work.
The idea to include the ``context'' (J.T.s word) in the request is
interesting. At present, switching ``contexts'' implicitly switches
both the address space and the register file. We'd need to figure out
if all commands should take that. J.T. Have you ever thought of a cpu
as a context? Considered the possibility of different contexts having
different architectures?
When it comes to:
It might be convienent to have separate (but potentially
overlapping) register files for integer registers, floating
point registers, system registers, miscellaneous registers,
etc.
I think the register file should contain the raw minimum (no
overlapping). GDB has to get its act to gether and better handle
overlapping registers.
What would I suggest? Both of course .... :-) They are solving
different problems.
Andrew