Re: GDB plugin proposal

[Scott Moser <ssmoser at us dot ibm dot com>]

On Mon, 22 Apr 2002, Fernando Nasser wrote:
> Scott Moser wrote:
> >
> >    - From what I understand (not a lawyer), modules would be required to
> >      be GPLed for a few reasons:
> >       1. to call 'add_cmd' you need to include gdbcmd.h , which is GPLed
>
> Leave the call to add_cmd() inside gdb, in the code that loads a
> plug-in.
> So, your plug-in code just provides a description in a standard format
> and does not have to include the GPL'ed header file.
>
> Besides, we may change add_cmd() and plug-ins would stop working, so it
> is
> better to define and interface at a higher level of abstraction anyway.
>

   I hadn't thought about the abstraction layer.  It is nice because it
removes external dependencies on GDB's header files and function
prototypes/operation.  The problem with it is that it then only allows
plugins to call GDB functions that it explicitly allows, where as with
the other method (including .h files and calling GDB functions directly
from within the plugin) the plugin can call any GDB function that may
benefit it.
   add_cmd() was the most obvious function that a plugin would want to
call, but others may prove to be of importance as well.
   Any thoughts ?  Would people rather have a possibly more powerful
plugin interface that potentially breaks when GDB changes, or one that
doesn't open up as much infrastructure of GDB ?
   My personal feeling is that the abstraction layer may end up being an
large amount of work, since for every GDB function that might prove
useful to a plugin would then need an abstracted wrapper around it.
Just from glancing through the code, other functions that come to mind
as possibly being useful are insert_breakpoints(), remove_breakpoints()
... (again, i'm sure others can think of more).

   Without the abstraction layer in place, the plugin interface looks
very similar to the linux kernel module interface which proves to at
very least be an acceptable model.  plugins (or modules for linux) are
the ones required to do the work to be compatible across different
versions.  This requires little to no work at all by the maintainers of
the kernel.
   I now realize that there would need to be a function exported by the
plugin interface to query the version of GDB, so the plugin could decide
whether or not it could work.  The 'plugin_init' function returns an int
for success/failure.

   My understanding is that binary modules in either method would not be
allowed unless the GDB maintainers and/or the FSF explicitly allowed
them . Thats fine by me, my discussion of that point was primarily to
keep GDB maintainers and the FSF from thinking that this would allow
proprietary use of GPLed code, without their consent.

> >       4. the README from gdb/gdbtk/library/plugins/HOW-TO mentions "As the
> >       plug-ins will be loaded into Insight/GDB for execution, the terms of
> >       the GPL also apply to the plug-in code."  I believe the same would
> >       apply for plugins of this nature.
>
> I wrote that based on list discussions (among Engineers, mind you -- not
> lawyers).  It is based on the assumption that only general purpose
> libraries
> that are part of the standard OS distribution (or a major component) can
> be binary only. But that is the conservative approach.
>

   My feeling is that this is really comparable to the linux kernel.  I
was under the impression that RMS had made comments that the binary only
kernel modules wouldn't be legal, except that Linus explicitly allowed
them.  (I'm sure there are lawyers that get good laughs out of
discussions like this, similar to me laughing at IP lawyers attempts to
understand coding )

> >    - if 'plugin unload' proves difficult (at first glance, it seems maybe), it
> >      could possibly be left out, as loading and unloading doesn't provide much
> >      foreseeable benefit
>
> Someone can have created user defined commands, added commands to
> breakpoints
> etc.  It can be done but will require a major rewrite of CLI code.  I
> also
> believe it does not add much and doesn't worth the effort.
>

   Thats my feeling too.  the only immediate benefit i see in having it
is in the debugging of a plugin that you were writing.  you wouldn't
have to exit gdb and load the plugin again, just unload and load.  most
of that hassle could be gotten around with a script to run gdb or
something though.

> >    - Its possible that GDB would eventually want to allow an LGPL like
> >      interface for plugins so that binary only plugins could be created.
>
> We are trying to create a libgdb which would be used to create the
> interactive debugger as well as be incorporated into other tools.
> Once this is achieved, the possibility of making the libgdb a LGPL'ed
> library will have to be discussed.

   I'd seen the discussions of libGDB before.  when I first saw them, I
was excited.  I think that this plugin model allows *some* of the
functionality that libGDB would give, and might at least give an idea of
some of the things people would do with a libGDB.

Scott Moser
Software Engineer; Linux Technology Center
IBM Corp., Austin, Tx
(512) 838-1533   T/L: 678-1533
ssmoser@us.ibm.com , internal zip: 9812