GDB plugin proposal

[Scott Moser <ssmoser@us.ibm.com>]

   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