From: Linus Torvalds on


On Wed, 9 Jun 2010, David Howells wrote:
>
> Implement the GDB remote protocol 'p' command to retrieve a single register
> value.

Is there any value to this? Apparently it used to work just because that
command never did anything (rather than return an error). Why not just
reinstate that behavior instead?

There's doesn't seem to be any reason to implement the single-register
case unless there is some legacy use of it. There's a good reason gdb
tends to use the "register block" thing, and it tends to be easier to
implement too (no crazy case statements etc).

Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Linus Torvalds on


On Wed, 9 Jun 2010, Frank Ch. Eigler wrote:
>
> Sure, much less data to transfer across a slowish serial link.

Umm. Or more? If you look at one register, you tend to look at several.
And we're not exactly talking kilobytes here.

Anyway, the existing patch is certainly easy to make a judgment on: it's
not a regression fix but a new feature, so I'm not applying it. I was
suggesting _making_ it a regression fix, but I really don't care.

Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
From: Jason Wessel on
On 06/09/2010 01:23 PM, Frank Ch. Eigler wrote:
> Linus Torvalds <torvalds(a)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.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo(a)vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/