This is the mail archive of the gdb@sourceware.cygnus.com mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: Remote protocol extension for register ranges


"J.T. Conklin" wrote:
> 
> >>>>> "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.
> 
I agree.  But as you say below, the G packet is a little more complex
and 
we have the P packet already.  I was planning on using P for writes.



> 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.
> 
Yes, the run time test (as it is done for P packets) is the idea.


> Adding parameters to the "G" command packet is more troublesome ---
> the register values immediately follow the command character.
> 
I was thinking of using 'P'...


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

This may be a nice option, and I would not discard it for the future 
(although I am not sure how I would use it from gdb without mixing some
different levels of information).

I am just planning on making a very small change to gdb and one of the 
stubs so the registers can be shown.  I don't think I will be given much
time to do that so I have to keep it very simple.  That is why I would
still
rather do the 'g' extension (for now) to be able to work with register
numbers
(while an eventual "yY" would work with byte offsets).

Note that this does not precludes the implementation of "yY" later, as
they
have different parameter types (regno's and offsets).  And we extend the
existing
command with the current type of arguments while the new ones, when
implemented,
will have a different type.

> 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.
> 
This looks like a time saving operation.  But other people that are
doing
threads work will know better than me.

We can eventually add "t=NNNN,".  Its acceptance can be tested at run
time like the other optimizations/extensions.



-- 
Fernando Nasser
Red Hat, Inc. - Toronto                 E-Mail:  fnasser@redhat.com
2323 Yonge Street, Suite #300           Tel:  416-482-2661 ext. 311
Toronto, Ontario   M4P 2C9              Fax:  416-482-6299

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]