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]

Re: [RFC] plugin/extension interface


Daniel Jacobowitz wrote:
On Sat, Dec 03, 2005 at 01:41:35PM +1100, Russell Shaw wrote:

Months ago, i added a remote protocol for a hardware in-circuit emulator
and was going to write a chapter documenting how to add a target protocol
to gdb. My questions on how best to add this to gdb in cvs got no response
whatsoever. Now i've lost all interest.

[Off-topic here, but]


I can't even remember seeing messages from you on this topic; a certain
amount of persistance is always called for in GDB development.

However, in general, I've come to believe that GDB shouldn't continue
to add support for new remote protocols.  What we need is a nice,
open-source framework for gdb remote <-> other remote conversion.

The way gdb works, when i type: target avrjtagice -d /dev/ttyS2, gdb uses (or registers) using: void _initialize_remote_jtag (void).

It really looks like gdb is "loading" the module.

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.

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.

With the specific interface in gdb, the performance was wonderful, and new gdb
commands can be easily registered for this ICE, that are only accessible after
the command "target avrjtagice -d /dev/ttyS2" is performed (like an emacs minor
mode or whatever).

Currently, the files for these specific interfaces are just chucked into gdb-6.3/gdb/
(such as remote-e7000.c).

What's really needed is a separate sub-directory for each of these remote-interface
protocol files, and a well documented api for what functions to use within them.
The api already exists, just look in any db-6.3/gdb/remote*.c. One of the subdirectories
can be devoted to the generic target protocol where the comms is to the end embedded
system, instead of an intermediate debugger box.


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