Re: [RFC] plugin/extension interface

[Russell Shaw <rjshaw@netspace.net.au>]

Daniel Jacobowitz wrote:
> On Sat, Dec 03, 2005 at 02:13:11PM +1100, Russell Shaw wrote:
> 
>>The way gdb works, when i type: target avrjtagice -d /dev/ttyS2,
>>gdb uses (or registers) using: void _initialize_remote_jtag (void).
> 
> Incorrect; that happens at GDB startup.
> 
>>If the functions (or framework) used in these target interfaces are
>>documented, the problems would be solved with little other than a bit
>>of documentation work.
> 
> Not unless we declared them a public interface.  That means supporting
> them, preserving compatibility, et cetera.  We are not prepared to do
> that.

Well that's just too bad. It's the best way to go. Atleast i can support
my own private gdb and cut the cruft that's been holding it back for years.

>>I couldn't use the default target protocol, because i wasn't interfacing
>>to an end target. I was interfacing to an ICE debugger (that already had
>>its own protocol) for the target.
>>
>>I did it to replace the current hack of having an extra program on the
>>pc that converts between the default gdb target protocol, and this ICE-
>>specific protocol.
>>
>>The conversion hack was extremely slow, clumsy, fault-intolerant, and 
>>error-prone.
> 
> I would need to know a lot more about these problems, but it is very
> likely that they are problems with the conversion program - not with
> the concept.  If they were problems with the remote protocol, we would
> be interested in fixing them.

The very concept of making a protocol conversion program act like an
end target is totally flawed.

First there's the tediousness of starting and initializing the converter
program and comms from it to the debugger box. Then the gdb<->debugger
comms must be established. Then the debugger<->embedded-system comms and
setup needs to be established using gdb.

Any hang-ups in the converter program or debugger means redoing the whole process.

The whole chain is extra slow because round-trip comms thru
gdb<->converter<->debugger<->target-system
is limited by the context switching of the pc between the gdb and converter processes.

There is also the extra tediousness of debugging the converter program and
trying to feed it with comms data using gdb, at the same time as having yet
another gdb to debug the actual converter.

The second problem is that ICE hardware and other debuggers have various specific
commands such as for setting ICE hardware parameters, selecting memory spaces,
setting breakpoint paramteters, and a ton of other stuff that a generic protocol
has no hope of addressing.

I found that by registering my own commands with add_com(), i can do all kinds
of excellent things such as spit out on the gdb output window a tabulated list
of the fuse settings in a microcontroller, or display and set the current ICE
hardware settings.

With a defined interface for vendors to control specific debugger hardware, gdb
would get a lot more interest and move lightyears ahead. All i've seen is stagnation
ever since i've had an interest in gdb 5 years ago.