[PATCH] plugin patch

[PATCH] plugin patch

[Scott Moser]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 19691 bytes --]

Below is a patch to add plugin support to GDB.  It exports a fairly
simple programmable interface for people to extend the functionality of
GDB via runtime loaded shared libraries in ways that may not fit with
the direction of the main GDB tree (not cross-platform, not stable,
niche audience...).

Also attached are two example plugins.  They've been tested on linux and
AIX, and some time ago on freebsd.

Changelog entry:

2002-10-28  Scott Moser <ssmoser@us.ibm.com>

	* Makefile.in (plugin.o): Add build line for plugin.c
	* configure.in: Add --enable-plugin option
	* config/powerpc/aix.mh: add -Wl,-bexpall on aix build
	* plugin.c: new file, plugin implementation
	* plugin.h: new file, header file for plugin.c
	* gdbplugin.h: new file for plugin use

gdb plugin architecture overview
- gdb user commands
   - plugin load
      takes a filename and loads it as a gdb plugin. searches the
      plugin-path if needed
   - plugin description
      takes a filename or number (of a loaded plugin) and calls its
      plugin_description function. if not implemented returns "description N/A"
   - plugin name
      takes a filename or number (of a loaded plugin) and calls its
      plugin_name function. if not implemented returns "name N/A"
   - plugin commands
      takes a filename or number (of a loaded plugin) and calls its
      plugin_commands function.  if not implmemented returns "commands N/A"
   - plugin list
      takes no arguments.  lists the currently loaded plugins.
   - plugin search [ verbose ]
      trys to open each file in the current plugin-path as a gdb plugin.
      lists filename and plugin-name for each plugin found.
      if 'verbose' is passed in, also call's plugins' 'description'
   - set plugin-path
      takes a string and sets it to the ":" delimited search path

- functions implemented by gdb plugins
   - plugin_init (required)
      prototype: int plugin_init(const char * version, char * args, int tty)
         - version is character string describing GDB's version
         - args are user specified arguments after the filename in 'plugin load'
         - tty is gdb's tty
         - returns true or false on success/failure of load
         - It is expected that in this function, the plugin will perform
           actions like:
            - on systems where '-rdynamic'-type symbol resolution isn't
              available, use dlsym() to access the functions it requires within
              gdb (or, potentially, other plugins).  For example, the functions
              "add_cmd", "add_set_cmd", etc.
            - call "add_cmd" to add its plugin-specific commands to the gdb
              command set
            - call "add_set_cmd" to enable plugin-specific variables
      called at load of a plugin

   - plugin_name
      prototype: const char * plugin_name(void)
         - takes no arguments
         - returns a character string (short) "name" for the plugin.
      called by 'plugin "name|list|search"'

   - plugin_commands
      prototype: const char * plugin_commands(void)
         - takes no arguments
         - returns a string describing the list of commands registered (or that
           will be registered) by the plugin.
      called by 'plugin commands'

   - plugin_description
      prototype: const char * plugin_description(void)
         - takes no arguments
         - returns a character string "description" of the command.
      called by 'plugin "name|list|search verbose"'


- implementation notes
   - expect users to call 'plugin_commands', 'plugin_description', and
     'plugin_name' before plugin_init is called.
     For example, by 'plugin search'
   - plugin_init will only be called on load.
   - if you check the version passed in to decide if you'll run or not,
     consider offering a 'force' option to load even if you don't think you
     should

- issues:
   - colon ":" is the search path separator.  this may cause problems on
     windows with its C:\ like filenames.  At this point, the plugin design
     will not work on windows anyway, as windows requires explicitly exporting
     functions for them to be accessible outside of main (no -rdynamic)
   - uses printf_filtered
   - the version string format changes between releases and cvs

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


diff -uprN ../src-20021028.sparce/gdb/Makefile.in gdb/Makefile.in
--- ../src-20021028.sparce/gdb/Makefile.in	2002-10-28 13:53:34.000000000 -0600
+++ gdb/Makefile.in	2002-10-28 14:46:43.000000000 -0600
@@ -1968,6 +1968,9 @@ parse.o: parse.c $(defs_h) $(gdb_string_
 	$(frame_h) $(expression_h) $(value_h) $(command_h) $(language_h) \
 	$(parser_defs_h) $(gdbcmd_h) $(symfile_h) $(inferior_h) \
 	$(doublest_h) $(builtin_regs_h) $(gdb_assert_h)
+plugin.o: plugin.c $(defs_h) $(frame_h) $(inferior_h) $(target_h) $(gdbcmd_h) \
+	$(language_h) $(symfile_h) $(objfiles_h) $(completer_h) $(value_h) \
+	$(gdb_string_h) $(gdbcore_h) $(gdb_stat_h) $(xcoffsolib_h)
 ppc-bdm.o: ppc-bdm.c $(defs_h) $(gdbcore_h) $(gdb_string_h) $(frame_h) \
 	$(inferior_h) $(bfd_h) $(symfile_h) $(target_h) $(gdbcmd_h) \
 	$(objfiles_h) $(gdb_stabs_h) $(serial_h) $(ocd_h) $(ppc_tdep_h) \
diff -uprN ../src-20021028.sparce/gdb/config/powerpc/aix.mh gdb/config/powerpc/aix.mh
--- ../src-20021028.sparce/gdb/config/powerpc/aix.mh	2002-10-28 13:53:34.000000000 -0600
+++ gdb/config/powerpc/aix.mh	2002-10-28 13:26:31.000000000 -0600
@@ -6,6 +6,7 @@ NAT_FILE= nm-aix.h
 NATDEPFILES= fork-child.o infptrace.o inftarg.o corelow.o rs6000-nat.o \
 	     xcoffread.o xcoffsolib.o

+LOADLIBES= -Wl,-bexpall
 # When compiled with cc, for debugging, this argument should be passed.
 # We have no idea who our current compiler is though, so we skip it.
 # MH_CFLAGS = -bnodelcsect
diff -uprN ../src-20021028.sparce/gdb/configure.in gdb/configure.in
--- ../src-20021028.sparce/gdb/configure.in	2002-10-28 13:53:34.000000000 -0600
+++ gdb/configure.in	2002-10-28 14:44:44.000000000 -0600
@@ -665,6 +665,30 @@ case ${enable_gdbmi} in
     ;;
 esac

+dnl Enable gdb plugin interface
+AC_ARG_ENABLE(plugin,
+[  --enable-plugin           Enable GDB plugin interface],
+[
+  case "${enable_plugin}" in
+    yes ) if test x$gdb_cv_os_cygwin = xyes; then
+            AC_MSG_ERROR(plugin will not work on win32; disabled)
+          fi ;;
+    no) ;;
+    "")  enable_plugin=yes ;;
+    *)
+      AC_MSG_ERROR(Bad value for --enable-plugin: ${enableval})
+    ;;
+  esac
+],
+[enable_plugin=yes])
+case ${enable_plugin} in
+  "yes" )
+      CONFIG_OBS="${CONFIG_OBS} plugin.o"
+      CONFIG_SRCS="${CONFIG_SRCS} plugin.c"
+      CONFIG_INITS="${CONFIG_INITS} plugin.c"
+    ;;
+esac
+
 # Configure UI_OUT by default (before 5.2 it can be disabled)
 # It must be configured if gdbmi is configured

diff -uprN ../src-20021028.sparce/gdb/gdbplugin.h gdb/gdbplugin.h
--- ../src-20021028.sparce/gdb/gdbplugin.h	1969-12-31 18:00:00.000000000 -0600
+++ gdb/gdbplugin.h	2002-10-28 13:26:31.000000000 -0600
@@ -0,0 +1,11 @@
+/* this file exists as a convienence for gdb plugin programming
+ * it will hopefully include all the gdb header files that a plugin
+ * developer would want to use
+ * */
+#include "defs.h"
+#include "gdbcmd.h"
+#include "gdbcore.h"
+#include "completer.h"
+#include "value.h"
+#include "valprint.h"
+#include "language.h"
diff -uprN ../src-20021028.sparce/gdb/plugin.c gdb/plugin.c
--- ../src-20021028.sparce/gdb/plugin.c	1969-12-31 18:00:00.000000000 -0600
+++ gdb/plugin.c	2002-10-28 13:26:31.000000000 -0600
@@ -0,0 +1,468 @@
+#include "plugin.h"
+#include "defs.h"
+#include "gdbcmd.h"
+#include "gdbcore.h"
+#include "completer.h"
+#include "dlfcn.h"
+#include "dirent.h"
+#include "version.h"
+#include <sys/stat.h>
+#include <string.h>
+
+static struct plugin* newPlugin(void *, const char *);
+static struct plugin* findPlugin(const char *);
+static struct plugin* findPluginByNum(int);
+static const char * searchPluginPath(const char * );
+static void * openPlugin(const char * ,int, char *, int );
+static void * getPluginHandle(const char *);
+static const char * callPluginInfoFunction(void *,char *,const char *fallback);
+
+static char *plugin_path;
+
+static struct plugin * pluginList;
+
+void
+plugin_list(int tty)
+{
+   /* list the plugins currently loaded */
+   const struct plugin * curp=pluginList;
+   if(curp==NULL)
+   {
+      printf_filtered("no plugins loaded\n");
+      return;
+   }
+   while(curp!=NULL)
+   {
+      printf_filtered("%i %s %s\n", curp->num, curp->filename, plugin_name(curp->handle));
+      curp=curp->next;
+   }
+   return;
+}
+
+const char *
+plugin_commands(void * handle)
+{
+   return callPluginInfoFunction(handle,"plugin_commands","commands N/A");
+}
+
+const char *
+plugin_name(void * handle)
+{
+   return callPluginInfoFunction(handle,"plugin_name","name N/A");
+}
+
+const char *
+plugin_description(void * handle)
+{
+   return callPluginInfoFunction(handle,"plugin_description","description N/A");
+}
+
+const char *
+callPluginInfoFunction(void * handle,char * funcname,const char *fallback)
+{
+   const char * (*func)(void);
+   const char * ret=NULL;
+   if(handle && funcname)
+   {
+      func=dlsym(handle,funcname);
+      if(func)
+      {
+         ret=func();
+      }
+   }
+   return (ret) ? ret : fallback;
+}
+
+void
+plugin_search(const char * str, int tty, int verbose)
+{
+   /* searches the current path for files with plugin_init() defined. */
+   if(plugin_path!=NULL)
+   {
+      const char *tok;
+      char *spath=(char*)malloc((strlen(plugin_path)+1)*sizeof(char));
+      if(spath==NULL)
+         return;
+      strcpy(spath,plugin_path);
+      tok=strtok(spath,":");
+      while(tok!=NULL)
+      {
+         struct dirent *direntry;
+         DIR * dir=opendir(tok);
+         if (dir!=NULL)
+         {
+            while((direntry=readdir(dir))!=NULL)
+            {
+#if (defined(DT_REG) && defined(DT_LNK) && defined(DT_UNKNOWN))
+               if (direntry->d_type==DT_REG || direntry->d_type==DT_LNK || direntry->d_type==DT_UNKNOWN)
+               {
+#endif
+                  void *handle=NULL;
+                  char *filename=(char*)malloc((strlen(tok)+strlen(direntry->d_name)+2)*sizeof(char));
+                  if(filename==NULL)
+                  {
+                     free(spath);
+                     return;
+                  }
+                  sprintf(filename,"%s/%s",tok,direntry->d_name);
+                  handle=openPlugin(filename,0,(char *)NULL, tty);
+                  if(handle!=NULL)
+                  {
+                     printf_filtered("%s : %s\n",filename,plugin_name(handle));
+                     if(verbose)
+                     {
+                        printf_filtered("\t%s\n",plugin_description(handle));
+                     }
+                     dlclose(handle);
+                  }
+                  free(filename);
+#if (defined(DT_REG) && defined(DT_LNK) && defined(DT_UNKNOWN))
+               }
+#endif
+            }
+         }
+         tok=strtok(NULL,":");
+      }
+   }
+   else
+   {
+      printf_filtered("plugin-path not set\n");
+   }
+   return;
+}
+
+void
+plugin_load(const char * filename, char * args, int tty)
+{
+   /* load a plugin named filename, (searching plugin-path if set )
+    * with args given
+    * */
+   void *handle=NULL;
+
+   handle=openPlugin(filename,1,args, tty);
+   if(handle==NULL)
+   {
+      const char *tempfile;
+      tempfile=searchPluginPath(filename);
+      if(tempfile==NULL)
+      {
+         printf_filtered("plugin load: couldn't find %s\n",filename);
+         return;
+      }
+      handle=openPlugin(tempfile,1,args,tty);
+      if(handle==NULL)
+      {
+         printf_filtered("plugin load: couldn't load %s\n",tempfile);
+         return;
+      }
+   }
+
+   newPlugin(handle,filename);
+   return;
+}
+
+void *
+getPluginHandle(const char * filename)
+{
+   struct plugin * cur;
+   void * handle;
+   cur=findPlugin(filename);
+   if(cur!=NULL)
+   {
+      handle=cur->handle;
+   }
+   else
+   {
+      const char * fullpath;
+      fullpath=searchPluginPath(filename);
+      handle=openPlugin(fullpath,0,(char *)NULL, 0);
+   }
+   return(handle);
+}
+
+struct plugin *
+newPlugin(void * handle, const char * filename)
+{
+   /* add this plugin at the beginning of the list */
+   struct plugin* newP;
+   newP=(struct plugin*)malloc(sizeof(struct plugin)+strlen(filename)*sizeof(char)+1);
+   if(newP==NULL)
+   {
+      printf_filtered("Failed to allocate space for plugin %s\n",filename);
+      return NULL;
+   }
+   newP->handle=handle;
+   newP->next=pluginList;
+   newP->filename=(char*)(newP+1);
+   strcpy(newP->filename,filename);
+   if(newP->next!=NULL)
+   {
+      newP->num=(int)((newP->next)->num)+1;
+   }
+   else
+   {
+      newP->num=0;
+   }
+   pluginList=newP;
+   return newP;
+}
+
+struct plugin *
+findPluginByNum(int num)
+{
+   struct plugin * cur;
+
+   for ( cur = pluginList; cur != NULL; cur = cur->next )
+   {
+      if (cur->num == num) break;
+   }
+   return cur;
+}
+
+struct plugin *
+findPlugin(const char * filename)
+{
+   /* find a plugin by filename from the plugin_list */
+   struct plugin * cur;
+
+   for ( cur = pluginList; cur != NULL; cur = cur->next )
+   {
+      if (strcmp(filename,cur->filename) == 0) break;
+   }
+   return cur;
+}
+
+void *
+openPlugin(const char * filename,int init, char * args, int tty)
+{
+   /* opens a named filename.  if init is true, will call its init function
+    * and pass in args and tty
+    * */
+   void * handle;
+   int (*initfunc)(const char *, char *, int);
+
+   if(filename==NULL)
+      return(NULL);
+
+   handle=dlopen(filename,RTLD_LAZY);
+   if(handle==NULL)
+      return(NULL);
+
+   if(!init)
+      return(handle);
+
+   initfunc=dlsym(handle,"plugin_init");
+
+   if(initfunc==NULL)
+   {
+      printf_filtered("couldn't find plugin_init in plugin %s\n",filename);
+      dlclose(handle);
+      return(NULL);
+   }
+
+   if(initfunc(version,args,tty))
+   {
+      printf_filtered("successfully loaded plugin %s\n",filename);
+      return(handle);
+   }
+   else
+   {
+      printf_filtered("plugin_init failed %s\n",filename);
+      /*
+       * don't do a dlclose here to avoid possible segfault if
+       * failed load didn't clean itself up correctly
+       */
+   }
+   return(NULL);
+}
+
+
+const char *
+searchPluginPath(const char * filename)
+{
+   /* returns a full path to a file if it exists in search path */
+   if(filename!=NULL)
+   {
+      int found;
+      struct stat buf;
+      char *tok;
+      char *spath;
+      if(!stat(filename,&buf))
+      {
+         return(filename);
+      }
+      if(plugin_path!=NULL)
+      {
+         spath=(char*)malloc((strlen(plugin_path)+1)*sizeof(char));
+         if(spath==NULL)
+         {
+            return(NULL);
+         }
+         strcpy(spath,plugin_path);
+         tok=strtok(spath,":");
+         while(tok!=NULL)
+         {
+            char *fp=(char*)malloc(((strlen(filename)+strlen(tok)+2))*sizeof(char));
+            if(fp==NULL)
+            {
+               free(spath);
+               return(NULL);
+            }
+            sprintf(fp,"%s/%s",tok,filename);
+            if(!stat(fp,&buf))
+            {
+               free(spath);
+               return(fp);
+            }
+            free(fp);
+            tok=strtok(NULL, ":");
+         }
+         free(spath);
+      }
+   }
+   return(NULL);
+}
+
+void
+plugin_command (char *arg, int from_tty)
+{
+   /* top level 'plugin' command handler */
+   char * cmdtype;
+   char * filename;
+   char * cmdargs = NULL;
+   int start;
+   int arglen;
+   int plugNum;
+   char *endptr;
+   struct plugin *p;
+   void * dlhandle;
+   const char * retstr;
+
+   if(arg==NULL)
+   {
+      printf_filtered("plugin: need second level command (see 'help plugin')\n");
+      return;
+   }
+
+   if (!strcmp(arg,"search verbose"))
+   {
+      plugin_search("",from_tty,1);
+      return;
+   }
+   else if (!strcmp(arg,"search"))
+   {
+      plugin_search("",from_tty,0);
+      return;
+   }
+   else if (!strcmp(arg,"list"))
+   {
+      plugin_list(from_tty);
+      return;
+   }
+
+   // all remaining plugin commands require args
+   cmdtype=arg;
+   if ((endptr = strchr(arg,' ')) == NULL)
+   {
+         printf_filtered("plugin: Error no argument to plugin command \"%s\"\n",cmdtype);
+         return ;
+   }
+   *endptr = '\0';
+   filename = endptr + 1;
+   while(filename[0]!='\0' && filename[0]==' ') filename++;
+
+   if(filename[0]=='\0')
+      return ;
+
+   if(filename[0]=='"' && ((endptr=strchr(filename+1,'"'))!=NULL))
+   {
+         filename++;
+         *endptr='\0';
+         cmdargs=endptr+1;
+         if(endptr[1]=='\0') cmdargs=NULL;
+   }
+   else
+   {
+      if((endptr=strchr(filename,' '))!=NULL)
+      {
+         *endptr = '\0';
+         cmdargs=endptr+1;
+      }
+   }
+
+   if(!strcmp(cmdtype,"load"))
+   {
+      plugin_load(filename,cmdargs,from_tty);
+      return;
+   }
+
+   plugNum=(int)strtol(filename,&endptr,10);
+
+   if(endptr!=NULL && (*endptr)=='\0')
+   {
+      p=findPluginByNum(plugNum);
+      if(p==NULL)
+      {
+         printf_filtered("no plugin number %i loaded (\"plugin list\" for list)\n",plugNum);
+         return;
+      }
+      dlhandle=p->handle;
+   }
+   else
+   {
+      dlhandle=getPluginHandle(filename);
+   }
+
+   if (!strncmp(cmdtype,"commands",4))
+   {
+      retstr=plugin_commands(dlhandle);
+   }
+   else if (!strcmp(cmdtype,"name"))
+   {
+      retstr=plugin_name(dlhandle);
+   }
+   else if (!strncmp(cmdtype,"desc",4))
+   {
+      retstr=plugin_description(dlhandle);
+   }
+   else
+   {
+      printf_filtered("%s: not a plugin command\n",cmdtype);
+      return;
+   }
+
+   if(retstr!=NULL)
+   {
+      printf_filtered("%s\n",retstr);
+   }
+   else
+   {
+      printf_filtered("command \"%s\" not implemented in plugin %s\n",cmdtype,filename);
+   }
+}
+
+void
+_initialize_plugin(void)
+{
+   struct cmd_list_element *c;
+
+   c = add_cmd ("plugin", class_files, plugin_command,
+      "manage GDB plugins\n\
+a GDB plugin can add functionality to GDB and make use of GDB functionality\n\
+without modifiying the core to GDB.\n\
+load [args]      - loads and initializes a plugin, [ with args ]\n\
+desc[ription]    - print description for file/num\n\
+name             - print name for file/num\n\
+commands         - list commands given by file/num\n\
+search [verbose] - search current plugin-path for gdb plugins [ show desc ]\n\
+list             - list currently loaded plugins\n\
+" ,&cmdlist);
+   set_cmd_completer (c, filename_completer);
+
+   add_show_from_set(add_set_cmd("plugin-path",class_support,
+            var_string_noescape, (char*) &plugin_path,
+            "Set plugin search path\n", &setlist), &showlist);
+
+   pluginList=NULL;
+}
+
diff -uprN ../src-20021028.sparce/gdb/plugin.h gdb/plugin.h
--- ../src-20021028.sparce/gdb/plugin.h	1969-12-31 18:00:00.000000000 -0600
+++ gdb/plugin.h	2002-10-28 13:26:31.000000000 -0600
@@ -0,0 +1,21 @@
+#if !defined (PLUGIN_H)
+#define PLUGIN_H 1
+
+extern void plugin_load(const char *, char *, int);
+extern void plugin_command (char *, int);
+extern void plugin_list(int);
+extern void plugin_search(const char * , int ,int );
+extern const char * plugin_name(void *);
+extern const char * plugin_description(void*);
+extern const char * plugin_commands(void*);
+
+extern char *plugin_path;
+
+struct plugin {
+   void * handle;
+   int num;
+   struct plugin * next;
+   char * filename;
+};
+
+#endif /* !defined (PLUGIN_H) */

[-- Attachment #2: Type: APPLICATION/OCTET-STREAM, Size: 2826 bytes --]

Re: [PATCH] plugin patch

[Eli Zaretskii]

On Mon, 28 Oct 2002, Scott Moser wrote:

> Below is a patch to add plugin support to GDB.  It exports a fairly
> simple programmable interface for people to extend the functionality of
> GDB via runtime loaded shared libraries in ways that may not fit with
> the direction of the main GDB tree (not cross-platform, not stable,
> niche audience...).

IIRC, the FSF doesn't like to add to GNU software support for dynamically 
loading arbitrary modules (for fear of non-free libraries being used thru 
this).

In any case, if this is approved, please consider documenting it in 
gdbint.texinfo.  TIA

Re: [PATCH] plugin patch

[Paul A. Clarke]

On Tue, 2002-10-29 at 00:27, Eli Zaretskii wrote:
> On Mon, 28 Oct 2002, Scott Moser wrote:
> > Below is a patch to add plugin support to GDB.  It exports a fairly
> > simple programmable interface for people to extend the functionality of
> > GDB via runtime loaded shared libraries in ways that may not fit with
> > the direction of the main GDB tree (not cross-platform, not stable,
> > niche audience...).
> 
> IIRC, the FSF doesn't like to add to GNU software support for dynamically 
> loading arbitrary modules (for fear of non-free libraries being used thru 
> this).

It would be a shame to shun useful functionality due only to a fear of
certain uses.  I know that, for other reasons, the Linux kernel added
licensing information to the kernel modules, to determine whether a
module would 'taint' the kernel.  If it would be helpful to add that
sort of information to the plugin interface to make the patch more
palatable, that could certainly be done.  This could also address
support issues where, for example, GDB crashes because of a bad plugin. 
One could provide a lower level of support (or none) if GDB is
'tainted'.  I think the Linux kernel module licensing awareness was
added mostly to address support issues.

The important thing, though, is that this is very useful functionality
in a small and isolated patch.  One of our goals for making use of GDB
plugins is to add functionality which is "API-aware".  In other words,
add apriori knowledge of the internals or state of a library to GDB, to
greatly enhance the debugging capabilities of GDB **with respect to
that, and only that library**.

A plugin interface would allow that useful functionality without
requiring either library-specific changes to core GDB or maintaining a
GDB patch indefinitely.  Of course, the plugin itself has to be
maintained, especially without a "hardened" ABI (but that's a much
bigger deal for perhaps another day ;)

Regards,
Paul Clarke

Re: [PATCH] plugin patch

[Scott Moser]

All,
   I sent a patch to add plugin support to GDB under this subject last
week, and hadn't received a response other than the one below.
   I'll gladly document the plugin in gdbint.texinfo if needed.  IBM
made a copyright assignment agreement previously and I have the required
papers to assign this patch also.

   I don't think that beneficial functionality should be kept from gdb
simply because people might use it in unfriendly ways.  Anyone
interested in taking gdb functionality could still get the GDB source
and highjack that (which would even be less obvious to detect than
shipping a file and telling the user to "plugin load" it within GDB).

   If my patch was submitted incorrectly, there was something else
that I was missing, or anything else I'd need to change/update/add,
please let me know.

   Thanks,
   Scott


On Tue, 29 Oct 2002, Eli Zaretskii wrote:

>
> On Mon, 28 Oct 2002, Scott Moser wrote:
>
> > Below is a patch to add plugin support to GDB.  It exports a fairly
> > simple programmable interface for people to extend the functionality of
> > GDB via runtime loaded shared libraries in ways that may not fit with
> > the direction of the main GDB tree (not cross-platform, not stable,
> > niche audience...).
>
> IIRC, the FSF doesn't like to add to GNU software support for dynamically
> loading arbitrary modules (for fear of non-free libraries being used thru
> this).
>
> In any case, if this is approved, please consider documenting it in
> gdbint.texinfo.  TIA
>
>

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: [PATCH] plugin patch

[Jelmer Vernooij]

On Wed, Nov 06, 2002 at 08:45:18AM -0600, Scott Moser wrote about 'Re: [PATCH] plugin patch':
> All,
>    I sent a patch to add plugin support to GDB under this subject last
> week, and hadn't received a response other than the one below.
>    I'll gladly document the plugin in gdbint.texinfo if needed.  IBM
> made a copyright assignment agreement previously and I have the required
> papers to assign this patch also.

>    I don't think that beneficial functionality should be kept from gdb
> simply because people might use it in unfriendly ways.  Anyone
> interested in taking gdb functionality could still get the GDB source
> and highjack that (which would even be less obvious to detect than
> shipping a file and telling the user to "plugin load" it within GDB).

>    If my patch was submitted incorrectly, there was something else
> that I was missing, or anything else I'd need to change/update/add,
> please let me know.
One small suggestion; add some kind of version system for the plugins. 
The API for plugins might change in the future and you don't want bug
reports from users complaining that gdb segfaults when they're trying
to load a plugin. We had the same thing when implementing this in
samba.

Just my two eurocents, :-)

jelmer

> On Tue, 29 Oct 2002, Eli Zaretskii wrote:


> > On Mon, 28 Oct 2002, Scott Moser wrote:

> > > Below is a patch to add plugin support to GDB.  It exports a fairly
> > > simple programmable interface for people to extend the functionality of
> > > GDB via runtime loaded shared libraries in ways that may not fit with
> > > the direction of the main GDB tree (not cross-platform, not stable,
> > > niche audience...).

> > IIRC, the FSF doesn't like to add to GNU software support for dynamically
> > loading arbitrary modules (for fear of non-free libraries being used thru
> > this).

> > In any case, if this is approved, please consider documenting it in
> > gdbint.texinfo.  TIA



> 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

-- 
Jelmer Vernooij <jelmer@nl.linux.org> - http://nl.linux.org/~jelmer/
 15:51:44 up  3:40,  9 users,  load average: 0.11, 0.10, 0.08

Re: [PATCH] plugin patch

[Scott Moser]

On Wed, 6 Nov 2002, Jelmer Vernooij wrote:

> On Wed, Nov 06, 2002 at 08:45:18AM -0600, Scott Moser wrote about 'Re: [PATCH] plugin patch':
>
> >    If my patch was submitted incorrectly, there was something else
> > that I was missing, or anything else I'd need to change/update/add,
> > please let me know.
> One small suggestion; add some kind of version system for the plugins.
> The API for plugins might change in the future and you don't want bug
> reports from users complaining that gdb segfaults when they're trying
> to load a plugin. We had the same thing when implementing this in
> samba.

   While its not by any means ideal due to the changing format of the
GDB version, the patch did have a method for a plugin to require a
specific version of GDB.
   when the plugin is loaded, its passed the gdb version (from
gdb/version.in).  If it decides it can't work with that version, then it
can return false and the plugin loader will say "failed to load".
   This way, the weight is on the plugin to decide if it can run or not,
rather than GDB.  Is that something like what you were looking for?

>
> Just my two eurocents, :-)
>
> jelmer
>

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: [PATCH] plugin patch

[Jelmer Vernooij]

On Wed, Nov 06, 2002 at 09:13:44AM -0600, Scott Moser wrote about 'Re: [PATCH] plugin patch':
> On Wed, 6 Nov 2002, Jelmer Vernooij wrote:

> > On Wed, Nov 06, 2002 at 08:45:18AM -0600, Scott Moser wrote about 'Re: [PATCH] plugin patch':

> > >    If my patch was submitted incorrectly, there was something else
> > > that I was missing, or anything else I'd need to change/update/add,
> > > please let me know.
> > One small suggestion; add some kind of version system for the plugins.
> > The API for plugins might change in the future and you don't want bug
> > reports from users complaining that gdb segfaults when they're trying
> > to load a plugin. We had the same thing when implementing this in
> > samba.

>    While its not by any means ideal due to the changing format of the
> GDB version, the patch did have a method for a plugin to require a
> specific version of GDB.
>    when the plugin is loaded, its passed the gdb version (from
> gdb/version.in).  If it decides it can't work with that version, then it
> can return false and the plugin loader will say "failed to load".
>    This way, the weight is on the plugin to decide if it can run or not,
> rather than GDB.  Is that something like what you were looking for?
Plugins won't "know" the API that is used in newer versions of GDB, so
they can't really decide whether they are or are not compatible with
it. Only allowing plugins to be loaded with _exactly_ the same version 
as the gdb they are loaded into works well (same way the linux kernel
does).

If the plugins are using a small number of functions only, you
might want to consider using an API version number - whenever one of
these functions changes, you increase the version number. This would
allow plugins from various gdb versions (but with the same API
version) to be used without the need of recompiling.

Jelmer

Re: [PATCH] plugin patch

[Andrew Cagney]

> Plugins won't "know" the API that is used in newer versions of GDB, so
> they can't really decide whether they are or are not compatible with
> it. Only allowing plugins to be loaded with _exactly_ the same version 
> as the gdb they are loaded into works well (same way the linux kernel
> does).

That is correct.

Scott,

GDB's internals are undergoing massive change(1) and the various GDB 
interfaces reflect this.  A plug-in architecture only works when there 
is a stable published interface and GDB's current internal interfaces 
and mechanisms are about as far from `stable' and `published' as you can 
get :-/

Accepting this patch will create a situtation (actually very like the 
Linux kernel) where either:
- The plug-in developers play constant catch-up with GDB's evolving 
interfaces - every new release will require new plug-in.
- GDB's development stagnates because the plug-in developers depand the 
specification and support of an additional external interface (over and 
above MI(2)).

With regard to the modules that IBM and other vendors are planning on 
writing, can I encourage you to contribute them to the FSF?  That way, 
the entire Free Software Community would benefit (and this plug-in issue 
would be mute :-).

Andrew

(1) Don't believe me?  I'm currently commiting patches that eliminates 
registers[] from the core of GDB.  That interface, for too many many 
years, formed part of the foundation on which GDB was built.

(2) A long term MI objective is to define a set of interfaces that both 
MI and the CLI can use.  FernandoN made reference to this in responce to 
your original post.


> If the plugins are using a small number of functions only, you
> might want to consider using an API version number - whenever one of
> these functions changes, you increase the version number. This would
> allow plugins from various gdb versions (but with the same API
> version) to be used without the need of recompiling.
> 
> Jelmer
> 

Re: [PATCH] plugin patch

[Paul A. Clarke]

...a bit long, sorry...

On Wed, 2002-11-06 at 11:14, Andrew Cagney wrote:
> > Plugins won't "know" the API that is used in newer versions of GDB,
so
> > they can't really decide whether they are or are not compatible with
> > it. Only allowing plugins to be loaded with _exactly_ the same
version 
> > as the gdb they are loaded into works well (same way the linux
kernel
> > does).
 
> [...]  A plug-in architecture only works when there 
> is a stable published interface and GDB's current internal interfaces 
> and mechanisms are about as far from `stable' and `published' as you
can 
> get :-/
> 
> Accepting this patch will create a situtation (actually very like the 
> Linux kernel) where either:
> - The plug-in developers play constant catch-up with GDB's evolving 
> interfaces - every new release will require new plug-in.
> - GDB's development stagnates because the plug-in developers depand
the 
> specification and support of an additional external interface (over
and 
> above MI(2)).

I agree that the above cons are reasonable expectations, but it would
seem the same issues would arise regardless if the code is a plug-in or
just code which is bolted on and rebuilt every time.  The maintenance
issues are the same.  Indeed, if some bolted-on code is pulled into the
GDB base, then the GDB team become obligated to either maintain it
enough to get a successful build, or remove it entirely.  At least with
a plug-in, the maintenance of the plug-in is the responsibility of the
maintainter of the plug-in, not the GDB team.

Additionally, if the plug-in is considered generally useful, it could
always be pulled into the GDB base at any time (assuming copyright
ass't.), since we believe all GDB
plug-ins would necessarily be GPL'd.

The pros, then:
- maintenance of plug-in (playing catch-up) is the responsibility of the
plug-in maintainer, not the GDB team
- maintains code size of base GDB
- allows potentially large optional features without bloating GDB
- allows extensibility without requiring GDB source downloads, builds,
or frequent relinks
- arguably encourages innovation by allowing more flexibility in working
with and enhancing GDB
- the enabling patch itself is very small and isolated

The biggest con, then, is the lack of a stable interface.  As you say,
this is also a con for the Linux kernel.  However, it would be no worse
than the Linux kernel, and one could argue that the benefits with
respect to innovation far outweigh revisting a decision to allow them
(kernel modules) in the first place.

If there is any way to make the plug-in capability more palatable, we
can make those changes.  Perhaps each time a plug-in is loaded, a
warning is displayed, like "Plug-ins are not officially supported, so
please report *any* problems to the plug-in maintainer", and encourage
the plug-ins to advertise a maintainer URL.

Maybe instead of "plug-ins", from which some might infer a stable
plug-in API, we should use the term "modules", with similar
non-guarantees of API stability as with the Linux kernel??  :-)

> With regard to the modules that IBM and other vendors are planning on 
> writing, can I encourage you to contribute them to the FSF?  That way,
> the entire Free Software Community would benefit (and this plug-in
issue 
> would be mute :-).

Absolutely, any plug-ins developed for GDB should and will be GPL'd.

> GDB's internals are undergoing massive change(1) and the various GDB 
> interfaces reflect this.
> (1) Don't believe me?  I'm currently commiting patches that eliminates
> registers[] from the core of GDB.  That interface, for too many many 
> years, formed part of the foundation on which GDB was built.

This would seem at least in part to conflict with later comment:

> GDB's current architecture allows the relatively easy addition of new 
> components (a new language, a new remote backend, a new isa) - add the
> file to the source list and re-compile.  In theory, you don't need to
go 
> around modifying lots of headers and the like.
> 
> This is simply ``good design''.

If it is easy to add new components, would it be so hard to maintain a
plug-in?

> (2) A long term MI objective is to define a set of interfaces that
both 
> MI and the CLI can use.  FernandoN made reference to this in responce
to 
> your original post.

That's interesting, and I haven't heard about this before.  It sounds
like these interfaces would then also be good candidates for a plug-in
interface.  Would you agree?  Maybe we could help?

Just as an example, using Scott's plug-in enabling patch, I created a
plug-in which detects memory leaks and bad calls to free (any address
not previously returned by an allocation function).  (I'd be happy to
share it with the list if anyone is interested.)  One can
enable/suspend/resume/disable the detection logic at any time, and a
full report, including full backtraces is available.

This example is not large enough or niche enough to be a good example of
why plug-ins are a Good Thing, but one can easily see a similar plugin
with library-specific (e.g. libgtk, libqt, etc.) functionality that
probably wouldn't make sense to integrate directly into GDB.  Such a
plug-in could potentially be very large as well.

It's impractical to write something that sends commands to gdb over a
pipe for each such case where a plug-in would be useful, especially if
you need more than one similar case active simultaneously; it's not
acceptable to tell customers to go download GDB, apply a patch, and
build in order to get some neat functionality; and it's not reasonable
to expect that all potential plug-ins are good candidates for inclusion
in the GDB base.  Let each plug-in maintainer handle that work.  As you
said, "there is always more work to do."  :)  

Regards,
Paul Clarke

Re: [PATCH] plugin patch

[Andrew Cagney]

Scott,

Just a side note, in case you're planning on contributing further patches:

GDB follows the GNU coding standard:
http://www.gnu.org/prep/standards_toc.html

In addition, GDB has a number of additional conventions:
http://sources.redhat.com/gdb/current/onlinedocs/gdbint_13.html#SEC110

Some of these are checked mechanically:
http://sources.redhat.com/gdb/current/ari/
(You'll note that it is reporting some file name violations :-( ).

Andrew

Re: [PATCH] plugin patch

[Andrew Cagney]

> 
> I agree that the above cons are reasonable expectations, but it would
> seem the same issues would arise regardless if the code is a plug-in or
> just code which is bolted on and rebuilt every time.  The maintenance
> issues are the same.  Indeed, if some bolted-on code is pulled into the
> GDB base, then the GDB team become obligated to either maintain it
> enough to get a successful build, or remove it entirely.  At least with
> a plug-in, the maintenance of the plug-in is the responsibility of the
> maintainter of the plug-in, not the GDB team.

If someone contributes a new module to GDB then, most likely, the 
contributor will become the maintainer - both the GDB user community and 
the GDB developer community benefit.

> (2) A long term MI objective is to define a set of interfaces that
> 
> both 
> 
>> MI and the CLI can use.  FernandoN made reference to this in responce
> 
> to 
> 
>> your original post.
> 
> 
> That's interesting, and I haven't heard about this before.  It sounds
> like these interfaces would then also be good candidates for a plug-in
> interface.  Would you agree?  Maybe we could help?

Per my other reply, this is simply ``good design'.

> Just as an example, using Scott's plug-in enabling patch, I created a
> plug-in which detects memory leaks and bad calls to free (any address
> not previously returned by an allocation function).  (I'd be happy to
> share it with the list if anyone is interested.)  One can
> enable/suspend/resume/disable the detection logic at any time, and a
> full report, including full backtraces is available.

Cool!  Can you contribute it to the FSF so that it can be integrated 
into GDB?

Andrew

Re: [PATCH] plugin patch

[Paul A. Clarke]

On Wed, 2002-11-06 at 17:56, Andrew Cagney wrote:
> > Just as an example, using Scott's plug-in enabling patch, I created a
> > plug-in which detects memory leaks and bad calls to free (any address
> > not previously returned by an allocation function).  (I'd be happy to
> > share it with the list if anyone is interested.)  One can
> > enable/suspend/resume/disable the detection logic at any time, and a
> > full report, including full backtraces is available.
> 
> Cool!  Can you contribute it to the FSF so that it can be integrated 
> into GDB?

I'd love to!  The only issues, aside from paperwork, are:

- it's based on Scott's plug-in enablement patch
- it currently only works on x86 (tested on GNU/Linux)

This last point leads into my next pitch for plug-in support (you had to
expect it, right?  ;-)

Would you consider the following as valid reasons for supporting
optional functionality via a dynamically-loaded plug-in/module
mechanism?
- generally useful function which isn't yet ported to multiple
architectures
- useful function, but only to a niche audience
- useful function, but of significant size, large enough to warrant only
building and/or loading it when desired

For example, as I mentioned previously, function which has apriori
knowledge of specific libraries/APIs, or function which is very
architecture-specific.  Specific examples are numerous, and include:

- Scott started working on a GDB plug-in for libgtk, which would allow a
developer to 'somehow' highlight certain widgets on demand, given a
widget's handle
- a similar GDB plug-in for libGL, which can track the OpenGL state
machine and validate calls as they are made
- a GDB plug-in which can trace calls to a given API, with knowlege
about parameter types and ranges
- a potentially large plug-in for GDB which can make use of
processor-specific performance monitoring capabilities
- a potentially large plug-in for GDB which does really goofy things to
the inferior like code surgery or error correction on-the-fly

(No, I don't have examples of these.  Yet!  I wish I did.)  It didn't
take too much brainstorming to come up with what (I hope) are decent
examples where plug-in/module support would be useful (you wouldn't want
to integrate all of those into GDB, would you?) and would accelerate the
advancement of GDB into new and broader areas, and all code would
necessarily be GPL'd.

Regards (and thanks for your patience and attention!),
Paul Clarke

Re: [PATCH] plugin patch

[Andrew Cagney]

> On Wed, 2002-11-06 at 17:56, Andrew Cagney wrote:
> 
>> > Just as an example, using Scott's plug-in enabling patch, I created a
>> > plug-in which detects memory leaks and bad calls to free (any address
>> > not previously returned by an allocation function).  (I'd be happy to
>> > share it with the list if anyone is interested.)  One can
>> > enable/suspend/resume/disable the detection logic at any time, and a
>> > full report, including full backtraces is available.
> 
>> 
>> Cool!  Can you contribute it to the FSF so that it can be integrated 
>> into GDB?
> 
> 
> I'd love to!  The only issues, aside from paperwork,

Great, sounds like a done deal!   I'm sure, as a member of the FSF 
community, and a willing contributor, you'll get that paper work problem 
resolved in no time.

> - it's based on Scott's plug-in enablement patch

Trivial to fix.

> - it currently only works on x86 (tested on GNU/Linux)

Writing it correctly makes it portable.  I'm sure, once you've got that 
paper work sorted, someone here will be willing to help you with the 
tweaks needed. After all, this is all part of being a memember of the 
FSF community.

Andrew

Re: [PATCH] plugin patch

[Klee Dienes]

We've also been using our own version of GDB plug-ins at Apple, and 
have found them to be rather handy at times.  Three examples of places 
where plug-ins have been used:

  * While doing performance analysis, I wrote a 100-line plug-in that 
hooks up GDB to a Mac OS X-specific performance monitoring library.  
The change is OSX-specific and uses Objective-C, and there's just about 
zero chance it would ever be appropriate for the main-line GDB sources, 
nor do I want it cluttering up our local branch when I'm not using it.  
But as a plug-in, I can just load it into my GDB when I need it for 
performance analysis.

* Our kernel developers sometimes find themselves dumping insanely 
nasty structures that can take quite a while to print using the core 
GDB.  GDB plug-ins let them write custom viewers/dumpers (typically 10x 
or more faster) without going through the hassle of maintaining a GDB 
tree or keeping custom binaries around.

* One of my crazy co-workers wrote a complete MacsBug front-end to GDB 
as a plug-in as a "nights and weekends" project.  This isn't something 
that we want to support in our core GDB sources, nor is it something 
I'd really expect the FSF folks to be particularly interested in 
picking up.  But it was a really cool hack, and one that was developed 
completely independently of our core GDB work.

On Thursday, November 7, 2002, at 01:02 PM, Paul A. Clarke wrote:
>
> - Scott started working on a GDB plug-in for libgtk, which would allow 
> a
> developer to 'somehow' highlight certain widgets on demand, given a
> widget's handle
> - a similar GDB plug-in for libGL, which can track the OpenGL state
> machine and validate calls as they are made
> - a GDB plug-in which can trace calls to a given API, with knowlege
> about parameter types and ranges
> - a potentially large plug-in for GDB which can make use of
> processor-specific performance monitoring capabilities
> - a potentially large plug-in for GDB which does really goofy things to
> the inferior like code surgery or error correction on-the-fly
>
> (No, I don't have examples of these.  Yet!  I wish I did.)  It didn't
> take too much brainstorming to come up with what (I hope) are decent
> examples where plug-in/module support would be useful (you wouldn't 
> want
> to integrate all of those into GDB, would you?) and would accelerate 
> the
> advancement of GDB into new and broader areas, and all code would
> necessarily be GPL'd.
>
> Regards (and thanks for your patience and attention!),
> Paul Clarke
>

Re: [PATCH] plugin patch

[Andrew Cagney]

> On Wed, 2002-11-06 at 13:12, Andrew Cagney wrote:
> 
>> > Instead of having to add this to the standard gdb as a one-off for NGPT,
>> > I can use the standard gdb and design them as plug-ins to be loaded only
>> > when debugging NGPT applications. This feels a lot cleaner and could be 
>> > applied for other gdb features/architectures to keep the core as small 
>> > and efficient as possible, loading additional support/features on demand
>> > only when needed.
> 
>> 
>> That is the theory already.  Reality differs though, there is always 
>> more work to do :-(.  That work is, however, independant of a plug-in 
>> module.
> 
> 
> Andrew,
> 
> Can you clarify what you mean here?  You seem to be implying that there
> are plans to support on demand (dynamic) loading of features, which
> sounds a lot like plug-ins.

GDB's current architecture allows the relatively easy addition of new 
components (a new language, a new remote backend, a new isa) - add the 
file to the source list and re-compile.  In theory, you don't need to go 
around modifying lots of headers and the like.

This is simply ``good design''.

Andrew

Re: [PATCH] plugin patch

[Paul A. Clarke]

On Wed, 2002-11-06 at 13:12, Andrew Cagney wrote:
> > Instead of having to add this to the standard gdb as a one-off for NGPT,
> > I can use the standard gdb and design them as plug-ins to be loaded only
> > when debugging NGPT applications. This feels a lot cleaner and could be 
> > applied for other gdb features/architectures to keep the core as small 
> > and efficient as possible, loading additional support/features on demand
> > only when needed.
> 
> That is the theory already.  Reality differs though, there is always 
> more work to do :-(.  That work is, however, independant of a plug-in 
> module.

Andrew,

Can you clarify what you mean here?  You seem to be implying that there
are plans to support on demand (dynamic) loading of features, which
sounds a lot like plug-ins.

Regards,
Paul Clarke

Re: [PATCH] plugin patch

[Andrew Cagney]

>> GDB via runtime loaded shared libraries in ways that may not fit with
>> the direction of the main GDB tree (not cross-platform, not stable,
>> niche audience...).
> 
> For folks like myself that are working on an alternate architecture or 
> runtime support components (in this case NGPT threads) this would be 
> very useful, as I can see several info commands that I would like to 
> add for M:N user mode scheduling state and LWP state display that would 
> be unique to NGPT and it's implementation. 

I suspect that if NGPT needs additional thread specific info commands 
then other thread implementations will be interested in similar. 
Extending the command set in a generic way also means that a user will 
find a consistent interface that works across thread implementations.

Cf, ``info vector'' which works (well should work) across Altivec, e500 
and i386.

> Instead of having to add this to the standard gdb as a one-off for NGPT,
> I can use the standard gdb and design them as plug-ins to be loaded only
> 
> when debugging NGPT applications. This feels a lot cleaner and could be 
> applied for other gdb features/architectures to keep the core as small 
> and efficient as possible, loading additional support/features on demand
> only when needed.

That is the theory already.  Reality differs though, there is always 
more work to do :-(.  That work is, however, independant of a plug-in 
module.

Andrew

Re: [PATCH] plugin patch

[Daniel Jacobowitz]

On Wed, Nov 06, 2002 at 07:47:13AM -0800, Howell, David P wrote:
> 
> On Mon, 28 Oct 2002, Scott Moser wrote:
> 
> > Below is a patch to add plugin support to GDB.  It exports a fairly
> > simple programmable interface for people to extend the functionality
> of
> > GDB via runtime loaded shared libraries in ways that may not fit with
> > the direction of the main GDB tree (not cross-platform, not stable,
> > niche audience...).
> For folks like myself that are working on an alternate architecture or 
> runtime support components (in this case NGPT threads) this would be 
> very useful, as I can see several info commands that I would like to 
> add for M:N user mode scheduling state and LWP state display that would 
> be unique to NGPT and it's implementation. 
> 
> Instead of having to add this to the standard gdb as a one-off for NGPT,
> I can use the standard gdb and design them as plug-ins to be loaded only
> 
> when debugging NGPT applications. This feels a lot cleaner and could be 
> applied for other gdb features/architectures to keep the core as small 
> and efficient as possible, loading additional support/features on demand
> only when needed.

You've both given good arguments in support of a general plugin
architecture.  No one's objecting to the theory (except possibly the
FSF... who this might need to be cleared with).  I object to the
implementation, however.

Scott, I'm sure you have a plugin or two in mind.  What interfaces do
they need?  What other interfaces would be useful?  I want plugins to
have a defined interaction with GDB, not be able to call into any
global function.  If I were you, I'd still want this, because then we
won't break your plugins willy-nilly.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

RE: [PATCH] plugin patch

[Howell, David P]

On Mon, 28 Oct 2002, Scott Moser wrote:

> Below is a patch to add plugin support to GDB.  It exports a fairly
> simple programmable interface for people to extend the functionality
of
> GDB via runtime loaded shared libraries in ways that may not fit with
> the direction of the main GDB tree (not cross-platform, not stable,
> niche audience...).
For folks like myself that are working on an alternate architecture or 
runtime support components (in this case NGPT threads) this would be 
very useful, as I can see several info commands that I would like to 
add for M:N user mode scheduling state and LWP state display that would 
be unique to NGPT and it's implementation. 

Instead of having to add this to the standard gdb as a one-off for NGPT,
I can use the standard gdb and design them as plug-ins to be loaded only

when debugging NGPT applications. This feels a lot cleaner and could be 
applied for other gdb features/architectures to keep the core as small 
and efficient as possible, loading additional support/features on demand
only when needed.

Thanks,
Dave Howell


-----Original Message-----
From: Scott Moser [mailto:ssmoser@us.ibm.com] 
Sent: Wednesday, November 06, 2002 9:45 AM
To: Eli Zaretskii
Cc: gdb-patches@sources.redhat.com
Subject: Re: [PATCH] plugin patch

All,
   I sent a patch to add plugin support to GDB under this subject last
week, and hadn't received a response other than the one below.
   I'll gladly document the plugin in gdbint.texinfo if needed.  IBM
made a copyright assignment agreement previously and I have the required
papers to assign this patch also.

   I don't think that beneficial functionality should be kept from gdb
simply because people might use it in unfriendly ways.  Anyone
interested in taking gdb functionality could still get the GDB source
and highjack that (which would even be less obvious to detect than
shipping a file and telling the user to "plugin load" it within GDB).

   If my patch was submitted incorrectly, there was something else
that I was missing, or anything else I'd need to change/update/add,
please let me know.

   Thanks,
   Scott


On Tue, 29 Oct 2002, Eli Zaretskii wrote:

>
> On Mon, 28 Oct 2002, Scott Moser wrote:
>
> > Below is a patch to add plugin support to GDB.  It exports a fairly
> > simple programmable interface for people to extend the functionality
of
> > GDB via runtime loaded shared libraries in ways that may not fit
with
> > the direction of the main GDB tree (not cross-platform, not stable,
> > niche audience...).
>
> IIRC, the FSF doesn't like to add to GNU software support for
dynamically
> loading arbitrary modules (for fear of non-free libraries being used
thru
> this).
>
> In any case, if this is approved, please consider documenting it in
> gdbint.texinfo.  TIA
>
>

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