GDB plugin proposal

GDB plugin proposal

[Scott Moser]

   I'd like to see what people here think about a way for GDB to load
'plugins' ( basically shared libraries that can be loaded via dlopen()
that can extend the command set and functionality of GDB by calling into
GDB functions such as add_cmd, add_com... )
   The plugins wouldn't be shipped with GDB, but instead by anyone who
wanted to implement a GDB command.  It would allow people to ship plugins
to do things that didn't necessarily fit in the main GDB tree.  Reasons
could be 'non cross-platform' code, small target base for command
(a particular dev community)...
   Please read what's below and let me know what you think.  I personally
feel that something like this adds great functionality to GDB at virtually
no cost.

Overview

   A 'plugin' command is added to GDB.  users then load plugins with
'plugin load path/to/filename.so' . GDB dlopen()s the file, dlsym()s for a
'plugin_init' function in the library and calls it if it finds it. that
function can then register commands or do other things with add_cmd, thus
extending the functionality of GDB...

Example Command Summary:
   Load Plugin:
      command: plugin load filename.so
      description: load the plugin
      notes: calls libraries plugin_init function
   Unload Plugin:
      command: plugin unload filename.so
      description: unload a plugin
      notes: call plugin_fini() if implemented. unload has to remove
         itself somehow from all the lists that GDB keeps for command
         searching etc.  (If it doesn't remove itself correctly, GDB
         could segfault )
   List Commands:
      command: plugin commands filename.so
      description: list the added/implemented by filename.so after it has
         been loaded
      notes: calls plugin_commands() from the file if implemented.  The
         reason for this is that the plugin may put its commands under
         appropriate headings.  this command allows for the user to list
         all the commands listed by this plugin
   Query Plugin:
      command: plugin query filename.so
      description: query a filename.so without loading to see what it will
         provide (description, commands...)
      notes: dlopen the library, call plugin_description() if implemented,
         and possibly plugin_commands() and print out the result. then close
         the library


Comments:
   - Possibly a 'plugin name' or 'plugin alias' command would be useful to
avoid retyping the filename each time.
   - 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
      2. similar situation to the linux kernel modules.  I had believed
      that binary only kernel modules were only seen as legal because
      Linus specifically allowed them.
      3. anyone shipping a binary only 'GDB plugin' would need tell
      their customers that that's what they were shipping, thus
      admitting use of GPLed code in a proprietary project.  Currently,
      someone would be more likely to just patch GDB, compile and ship
      without ever mentioning the word GDB.
      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.
   - since GDB is linked with '-rdynamic', no changes are required to GDB
     or its build process other than the 'plugin' command being added to
     allow plugins to call into GDB.
   - 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
   - Its possible that GDB would eventually want to allow an LGPL like
     interface for plugins so that binary only plugins could be created.

Pros
   - allow people outside of the core GDB team to implement distribute and
     test their plugins without modifying GDB.
   - allow GDB to take many more 'project centered' paths, ie different
     projects might write plugins to help them debug their specific
     project.
   - allow GDB to gain functionality of plugins without requiring
     maintenance by the core team
   - very small amount of work to enable.
Cons
   - puts external dependencies on the GDB api.  Currently changes to
     function names/prototypes/behavior only need to be resolved within
     GDB.  I'm not sure how stable the functions in command.h have
     historically been as I've not been around GDB that long
   - in order to be unloaded, a plugin must completely unregister-register
     itself from GDB to avoid GDB segfaults after a dlclose()
   - could possibly allow people to extend GDB without providing source
     (again, I'm not a lawyer).
   - plugin interface might not be available on all platforms (I'm only
     familiar with GNU/linux enough to know that it is possible there). It may
     not even be conceivable on other platforms.
   - could be argued that this is better done with a 'robot-like' app and
     a pipe.  ( I don't think this approach is as beneficial, and
     definitely not as fast )

Example Plugin Ideas

   - call graph generator - live updated xwindow of who is calling who
     while your program runs
   - heap watch - watch malloc requests and free calls to tell how big
     memory footprint is.
   - X debugger - command 'show window PtrToXLibWindow' could highlight
     which window the pointer was referencing.
   - would love to hear others ideas too... I'm sure I'm terribly
     non-creative


   Any/All input is highly appreciated.
   Scott

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

Re: GDB plugin proposal

[Fernando Nasser]

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.


>       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.


>    - 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.


>    - 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.





-- 
Fernando Nasser
Red Hat Canada Ltd.                     E-Mail:  fnasser@redhat.com
2323 Yonge Street, Suite #300
Toronto, Ontario   M4P 2C9

Re: GDB plugin proposal

[Fernando Nasser]

Fernando Nasser wrote:
> 
> >    - 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 should have mentioned that this is not happening that soon.  We have
come a long way from the monolithic GDB program, but there is still
quite
a bit of work to do and there is no funding for that at the moment.

This library was the central part of my parallel debugger, PGDB, which
I start to develop while a grad student at Univ. of Toronto circa 1993.
I have been trying to get a pure libgdb library done ever since. ;-)

-- 
Fernando Nasser
Red Hat Canada Ltd.                     E-Mail:  fnasser@redhat.com
2323 Yonge Street, Suite #300
Toronto, Ontario   M4P 2C9

Re: GDB plugin proposal

[Andrew Cagney]

> - 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.

An LGPL'd libgdb will simply not happen.

enjoy,
Andrew

Re: GDB plugin proposal

[Scott Moser]

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

Re: GDB plugin proposal

[Daniel Berlin]

> 
>    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.

RMS's viewpoint isn't legally relevant. He may be right. He may be wrong. 
He claims he's right, but that doesn't make it so.
He'd *like* to be right, but that also doesn't make it so.
Certainly, anything related to law that RMS spouts should be taken with a 
*large* grain of salt.

>   (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 )

Watch out, some of us soon-to-be IP lawyers are coders as well.
Muhahahahah
--Dan

Re: GDB plugin proposal

[Eli Zaretskii]

> Date: Tue, 23 Apr 2002 14:28:00 -0400 (EDT)
> From: Daniel Berlin <dberlin@dberlin.org>
> 
> RMS's viewpoint isn't legally relevant. He may be right. He may be wrong. 
> He claims he's right, but that doesn't make it so.
> He'd *like* to be right, but that also doesn't make it so.
> Certainly, anything related to law that RMS spouts should be taken with a 
> *large* grain of salt.

I think this is terribly unfair, and shouldn't have been sent except
perhaps in private email.  If you are going to ruin someone's
reputation in public, at least CC him so he would be able to defend
himself.

Re: GDB plugin proposal

[Per Bothner]

Eli Zaretskii wrote:
> I think this is terribly unfair, and shouldn't have been sent except
> perhaps in private email.  If you are going to ruin someone's
> reputation in public, at least CC him so he would be able to defend
> himself.

I think RMS counts as a "public figure" in this context ...
-- 
	--Per Bothner
per@bothner.com   http://www.bothner.com/per/

Re: GDB plugin proposal

[Daniel Berlin]

On Tue, 23 Apr 2002, Eli Zaretskii wrote:

> > Date: Tue, 23 Apr 2002 14:28:00 -0400 (EDT)
> > From: Daniel Berlin <dberlin@dberlin.org>
> > 
> > RMS's viewpoint isn't legally relevant. He may be right. He may be wrong. 
> > He claims he's right, but that doesn't make it so.
> > He'd *like* to be right, but that also doesn't make it so.
> > Certainly, anything related to law that RMS spouts should be taken with a 
> > *large* grain of salt.
> 
> I think this is terribly unfair, and shouldn't have been sent except
> perhaps in private email. 

Errr, how is it unfair?
He's not a lawyer.
I simply said that what he says related to law should therefore be taken 
with a grain of salt.
> If you are going to ruin someone's
> reputation in public, at least CC him so he would be able to defend
> himself.
Ruin someone's reputation?
How did i ruin his reputation?
What have I said that is untrue?
> 

Re: GDB plugin proposal

[Eli Zaretskii]

On Tue, 23 Apr 2002, Daniel Berlin wrote:

> > > RMS's viewpoint isn't legally relevant. He may be right. He may be wrong. 
> > > He claims he's right, but that doesn't make it so.
> > > He'd *like* to be right, but that also doesn't make it so.
> > > Certainly, anything related to law that RMS spouts should be taken with a 
> > > *large* grain of salt.
> > 
> > I think this is terribly unfair, and shouldn't have been sent except
> > perhaps in private email. 
> 
> Errr, how is it unfair?

You said his views are legally irrelevant.  You did that without cc'ing 
him.

> How did i ruin his reputation?
> What have I said that is untrue?

Since when ruining a reputation requires telling untrue things?  Is that 
what they teach you in law schools nowadays?

Re: GDB plugin proposal

[Daniel Berlin]

On Wed, 24 Apr 2002, Eli Zaretskii wrote:

> 
> On Tue, 23 Apr 2002, Daniel Berlin wrote:
> 
> > > > RMS's viewpoint isn't legally relevant. He may be right. He may be wrong. 
> > > > He claims he's right, but that doesn't make it so.
> > > > He'd *like* to be right, but that also doesn't make it so.
> > > > Certainly, anything related to law that RMS spouts should be taken with a 
> > > > *large* grain of salt.
> > > 
> > > I think this is terribly unfair, and shouldn't have been sent except
> > > perhaps in private email. 
> > 
> > Errr, how is it unfair?
> 
> You said his views are legally irrelevant.  You did that without cc'ing 
> him.
> 
He's not a judge.
His views are therefore legally irrelevant.
Heck, lawyer's views are technically legally irrelevant, since it's the 
judge who has the final say.

--Dan

Re: GDB plugin proposal

[Stan Shebs]

Daniel Berlin wrote:
> 
> >   (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 )
> 
> Watch out, some of us soon-to-be IP lawyers are coders as well.
> Muhahahahah
> --Dan

Hmmm, I think in your case we're going to want to see the JPEG of
your license to practice...

:-) :-)

Daniel Berlin, Esq - yup, that's going to take some getting used to!

Stan

Re: GDB plugin proposal

[Matthew Fyles]

For the Superh H architecture we have added a command called fork into GDB to allow the user to create a new process from the GDB command language in the same way that the shell command is implemented.

Basically the new process gets passed a pipe to the GDB command languange when created allowing the user application to talk directly to GDB. This allows you to add new code which can be executed whilst in a GDB session without adding new commands into GDB.

The main use we have for this at the momemt is to solve the problem of having to specify a port to a simulator that is driven via the GBD server interface. We fork a loader process from GDB which sets up the sockets for communication and then passes a target-remote command with the port number back into GDB which then connects to the simulator.

This interface has proved very useful and allows us to add whatever functionality we require without changing the source code for GDB (with the exception of the 20 lines required to add the fork command)

It will also work on all supported host platforms.

If this would be useful to anybody then let me know.