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>
- Subject: Re: Remote protocol extension for register ranges
- From: jtc at redback dot com (J.T. Conklin)
- Date: 22 Mar 2000 08:26:29 -0800
- Cc: gdb at sourceware dot cygnus dot com, Andrew Cagney <cagney at cygnus dot com>, taruna at redhat dot com, Eric Bachalo <ebachalo at cygnus dot com>
- References: <38D8CFA4.C3535C93@redhat.com>
- Reply-To: jtc at redback dot com
>>>>> "Fernando" == Fernando Nasser <fnasser@redhat.com> writes:
Fernando> Presently, the remote protocol can only read all registers
Fernando> of a target. This is OK for the context registers (the ones
Fernando> that are saved by the OD on a context switch) but this is a
Fernando> serious limitation for machines that have lots of additional
Fernando> registers. It is just not feasible to read them all at
Fernando> every "g" packet.
If a target has so many registers that you don't want to read them all
with the "g" command packet, I believe you are going to need something
similar for the "G" command packet. Otherwise, any read/modify/write
operations GDB does will end up reading and writing the entire set.
Fernando> I would like to add parameters to the "g" packet. Something
Fernando> similar has been proposed before -- the only difference is
Fernando> that I would like the parameters to be a register number or
Fernando> a register number range range.
You could probably get away with adding parameters to the "g" command
packet --- as far as I can tell none of the sample stubs completely
parse the command. But if GDB sent "g" command packet containing a
register range to such stubs, it would get the entire register set.
You would have to write a some sort of run time test to determine
whether it handled register ranges.
Adding parameters to the "G" command packet is more troublesome ---
the register values immediately follow the command character.
For these reasons, I recommend implementing a new set of commands
which would deprecate G/g/P/p.
Perhaps something like:
Get Registers:
y<start>,<end>
Set Registers:
Y<start>,<end>,<register-contents>
But while we are adding commands, we might want to consider whether
there are any other arguments we should add.
One that comes to mind is a thread-id. Currently, when we want to get
the registers from several threads on the target, GDB has to issue a
set thread command before each store/fetch register command. If the
thread-id was part of the request, it could significantly improve
remote protocol performance, especially on low-bandwidth and/or high
latency connections.
For amusement purposes only, I've enclosed the store and fetch
sections from the specification I've been writing for a replacement
remote protocol. Other than the register ranges being specified by
offset and length, it's pretty much the same as the above.
--jtc
4.1 REGISTER FETCH
input:
context_t id;
int offset; offset within register data
int length; length of transfer
output:
int status;
char data[];
This command may yeild unpredicable results if context <id> has not
been suspended.
issues:
This assumes a single flat address space for all registers.
It might be convienent to have separate (but potentially
overlapping) register files for integer registers, floating
point registers, system registers, miscellaneous registers,
etc.
For example, one register file could contain the PC, FP, SP,
and whatever other registers are needed on a particular
architecture for GDB after a signal/exception/breakpoint
event. This would solve the problem of what to return in
those events.
4.2 REGISTER STORE
input:
context_t id;
int offset; offset within register data
int length; length of transfer
char data[];
output:
int status;
This command may cause unpredictable behavior if context <id> has not
been suspended.
issues:
see also register fetch.
4.3 MEMORY FETCH
input:
addr_t address; address of transfer
int length; length of transfer
mode_t mode;
output:
int status;
char data[length];
description:
Returns the contents of the memory region at <address> through
<address> + <length>.
This command may yeild unpredictable results if all contexts which
access this memory region have not been suspended (unless some mutual
exclusion mechanism is employed).
issues:
should this command take a "address space" argument? This
might be useful for I/O space and bus spaces. If so, should
registers simply be considered a "space".
issues:
should this command take a context id argument as well? This
might be desirable if different contexts can have different
memory mappings.
4.4 MEMORY STORE
input:
addr_t address; address of transfer
int length; length of transfer
mode_t mode;
char data[length];
output:
int status;
description:
Writes data[] at <address> through <address> + <length>
This command may cause unpredictable results if all contexts which
access this memory have not been suspended (unless some mutual
exclusion mechanisms is employed).
issues:
see also memory fetch.
--
J.T. Conklin
RedBack Networks