This is the mail archive of the
mailing list for the GDB project.
GDB plugin proposal
- From: Scott Moser <ssmoser at us dot ibm dot com>
- To: gdb at sources dot redhat dot com
- Date: Mon, 22 Apr 2002 17:52:21 -0500 (CDT)
- Subject: GDB plugin proposal
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
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:
command: plugin load filename.so
description: load the plugin
notes: calls libraries plugin_init function
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 )
command: plugin commands filename.so
description: list the added/implemented by filename.so after it has
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
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
- 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
- Its possible that GDB would eventually want to allow an LGPL like
interface for plugins so that binary only plugins could be created.
- 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
- allow GDB to gain functionality of plugins without requiring
maintenance by the core team
- very small amount of work to enable.
- 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
Any/All input is highly appreciated.
Software Engineer; Linux Technology Center
IBM Corp., Austin, Tx
(512) 838-1533 T/L: 678-1533
firstname.lastname@example.org , internal zip: 9812