Re: [PATCH] FRV: Implement the GDB remote protocol 'p' command to retrieve a register

[Jason Wessel <jason.wessel@windriver.com>]

On 06/09/2010 01:23 PM, Frank Ch. Eigler wrote:
> Linus Torvalds <torvalds@linux-foundation.org> writes:
>
>   
>>> Implement the GDB remote protocol 'p' command to retrieve a single register
>>> value.
>>>       
>> Is there any value to this? [...]
>>     
>
> Sure, much less data to transfer across a slowish serial link.
>
>   

I have actually measured this before using a yet to be posted for review
version which works for x86, arm and mips.   The improvement is more
significant with the 64 bit archs vs the 32 because of the register
sizing.  The typical case of stepping is quite a bit more responsive
when you only need to read the pc, stack pointer and frame pointer.  At
the point in time I post the patches, I can also post the data about the
savings for two of the exact same work load sequences.

I had also tried out an implementation of the gdb extension which where
you can pass the pc, stack pointer and frame pointer along with the stop
code and this provides an additional speed up as well, but not nearly as
much of a gain as implementing the 'p' packets.

I don't know if I will have it ready for 2.6.36 or not, but the generic
use of the 'p' packet was also required so that the kdb shell could have
a mechanism to individually read and write registers.

I am a bit curious if the frv arch had considered migrating to the kgdb
core, vs continuing to use the separate gdbstub?   It would seem we are
duplicating the creation of the same sort of features.  The frv
architecture may not need it at all, but if you do make use of the kgdb
core, you get other features like kdb for free, plus any of the
interesting features you might want to add might be of interest to other
consumers of the kernel debugger.

Cheers,
Jason.