From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 30012 invoked by alias); 22 Apr 2002 22:52:17 -0000 Mailing-List: contact gdb-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sources.redhat.com Received: (qmail 29990 invoked from network); 22 Apr 2002 22:52:16 -0000 Received: from unknown (HELO brickies.austin.ibm.com) (192.35.232.241) by sources.redhat.com with SMTP; 22 Apr 2002 22:52:16 -0000 Received: from ssmoser (helo=localhost) by brickies.austin.ibm.com with local-esmtp (Exim 3.35 #1 (Debian)) id 16zmfV-00028n-00 for ; Mon, 22 Apr 2002 17:52:21 -0500 Date: Mon, 22 Apr 2002 15:52:00 -0000 From: Scott Moser X-X-Sender: ssmoser@brickies.austin.ibm.com To: gdb@sources.redhat.com Subject: GDB plugin proposal Message-ID: MIME-Version: 1.0 Content-Type: TEXT/PLAIN; charset=US-ASCII X-SW-Source: 2002-04/txt/msg00371.txt.bz2 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