From: Linus Torvalds on 9 Jun 2010 12:50 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 9 Jun 2010 14:30 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 28 Jun 2010 00:10 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/
|
Pages: 1 Prev: [ANNOUNCE] 2.6.33.5-rt23 Next: Removing dead CONFIG_GDB_CONSOLE |