GDB and remote protocols

[Russell Shaw]

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.