This is the mail archive of the
gdb@sourceware.org
mailing list for the GDB project.
Re: GDB and remote protocols
Daniel Jacobowitz wrote:
This is a bit tangential to the poll Jim's conducting, so I've changed
the subject.
On Wed, May 24, 2006 at 12:02:46PM +1000, Russell Shaw wrote:
I've done all this stuff for the AVR by adding my own comms handling
and memory-space/type handling code to gdb for communicating with a
specific jtag ice.
IMO, the generic stub thing should only be used for targets that
receive the commands without any intermediate ICE/debugger hardware
(these targets interpret gdb commands with their own software).
IMO, every supported hardware device (jtag debuggers etc) should
have their own directory in gdb. It is much easier to take advantage
of specific debugger features, instead of relying on lowest common
denominator features of the generic gdb stub shim thing. Shims add
unnecessary delay and cludginess because of the extra layer of comms
overhead.
We've talked about this before. I take the opposite view, and I think
the GDB community has been mostly moving in that direction. One of my
biggest motivations is that when GDB has extra code to support a
particular ICE, it is extremely unlikely that anyone making changes can
test with that ICE, and the code rots quickly. Most of the ones we've
got in the source tree right now are in pretty bad shape.
I'd just send an email to the tool maintainer to say what has changed in
the gdb interface, and let them adapt it. If there's no maintainer, tough.
If someone needs it, it'll soon get fixed. The same problem exists for shims
if the stub protocol is changed (tho it's less exposed to gdb changes).
I'd think the current non-maintained-ness of the hardware drivers in
gdb is more due to lack of documentation and policy guidelines. I only
found that stuff by accident, even after having searched for it in the
manual (couple of years ago).
Another way is for gdb to have a "dlopen" interface that loads whatever
hardware driver the user selects, so there wouldn't need to be any code
for specific hardware in gdb. An advantage over shims is less comms
overhead and less delays due to system process switches between gdb and
shim.
The other advantage is that there would be no need to change the generic
stub code to add features for hardware debuggers, which would impact 99%
of targets that connect directly to gdb.
My last six months of GDB work can basically be described by:
- Make the one remote protocol (remote.c) more powerful, so that it
is not restricted to lowest common denominator features, e.g.
support for autodetecting register sets.
- Make the remote protocol more efficient where the communication
overhead is a problem. Large packet size negotiation and quicker
feature probing are the subject of my current project, qSupported,
which I hope to have done Real Soon. Another project I've got
going would provide the infrastructure for binary memory reads
from the target (complementing the X packet for writes).
The code handled all the memory spaces the jtag ice supported, as well
hardware and software breakpoints, and self diagnostics. Code could be
uploaded and downloaded from the jtag ice, new jtag firmware uploaded etc.
It is easy to add your own gdb commands, which only exist when your specific
extension is enabled in gdb.
This is something we're obviously hearing needs to be supported. But
there's other ways to do it: for instance, having the stub report its
ICE name, and GDB search a local database for command files associated
with that target name, and do all the commands in a scripting language.
Wouldn't that be nicer than having to build a custom GDB binary? But,
of course, it only gets done when someone works on it.
[In theory you could even download commands from the stub; but that
presents some security questions that it might be best to simply
avoid.]
The shim approach may be ok, but i thought i should just state some
obvious points.