Re: [RFC] plugin/extension interface

[Daniel Jacobowitz <drow@false.org>]

On Fri, Dec 02, 2005 at 08:48:58PM +0200, Eli Zaretskii wrote:
> > Date: Fri, 02 Dec 2005 18:22:54 +0000
> > From: Andrew STUBBS <andrew.stubbs@st.com>
> > 
> > I would like to test the waters and find out what your opinion would be 
> > on the subject of a GDB plugin/extension interface.
> 
> Such suggestions (not only for GDB, for other GNU projects as well)
> are usually rejected by Richard Stallman and the FSF, because they
> make it possible to add to GDB significant new features with
> proprietary (i.e. non-free software) shared libraries, thus avoiding
> the need to release any parts of GDB under GPL.

I think we could discuss this with the FSF, if we had sufficiently
compelling reasons.  But, I don't think that we do, right now.

Andrew, I can't support an interface like the one you've described.
GDB is a hugely complicated program, with many independent areas; it's
not clear to me which of those areas you're trying to make pluggable. 
It looks to me like it is specifically the target interface - just a
very small piece of the pie.  Also, new CLI commands.

If that's right, the traditional solution to the target interface is a
third party program which acts as a conversion tool between the GDB
remote protocol and your proprietary target protocol, with whatever
glue logic you would otherwise put into the plugin.  The remote
protocol serves as the boundary interface in the same way that the DLL
boundary would serve as an interface.

If what you want can't be done that way because of shortcomings in
the protocol, we can fix them.  This keeps the already-existing,
documented, and supported remote protocol as the extent of GDB's
obligation to remote targets.  All the other bits you wanted to export
as methods have less clear semantics, and some of them are guaranteed
to change over time.  GDB is burdened already with support for a huge
number of targets using the _one_ interface; I don't want to deal with
backwards compatibility.

For new CLI commands, the right answer is probably to implement them
in-core in some scripting language, and optionally pass things back to
your remote target via "monitor" commands.  The existing scripting
language is inadequate.  You can find preliminary (but usable) perl
bindings in the mailing list archive.  I've hacked Guile into GDB in
the past, and when I can find some time, I intend to revisit the
general problem (probably using Python, this time, since I'm most
familiar with it at the moment).  This requires some MI interface
surgery and is not a small task.

-- 
Daniel Jacobowitz
CodeSourcery, LLC