This is the mail archive of the
gdb@sourceware.org
mailing list for the GDB project.
Re: [RFC] plugin/extension interface
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.