This is the mail archive of the gdb@sourceware.org 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]
Other format: [Raw text]

GDB and remote protocols


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.

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

-- 
Daniel Jacobowitz
CodeSourcery


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