This is the mail archive of the
gdb@sourceware.org
mailing list for the GDB project.
plugin interface for GDB
- From: Thiago Jung Bauermann <bauerman at br dot ibm dot com>
- To: gdb ml <gdb at sourceware dot org>
- Date: Fri, 20 Apr 2007 16:43:48 -0300
- Subject: plugin interface for GDB
Hi folks,
I am interested in developing a plugin interface for GDB, and would
like to know what are your thoughts about it. Would you find such
feature useful? Would it be integrated into GDB?
This is useful to me, so I'll probably do it even if there's no plan
to integrate the plugin interface upstream (in fact, I have a very
basic working prototype already). But if there is community interest in
such thing, I'd like to do it in a way that will increase its chance of
integration and shape it so that more people could benefit from it.
I saw some discussion on this subject in the following thread:
http://sourceware.org/ml/gdb/2002-04/msg00371.html
But it didn't come to a conclusion, so I'd like to revisit the idea.
Motivation for having a plugin interface:
- enable seamless debugging of programs written in multiple languages
(Java + C, Python + C, etc) (in fact, this is the reason I need the
plugin interface.)
- useful for specialized debugging (specific problem domain)
- lessens the need to maintain custom GDBs. You just use a standard GDB
and write a plugin (or use an existing one). If you decide to upgrade
GDB, you won't need to port your code and not even recompile the
plugin (ideally, if we manage to design a resilient interface).
- allow people outside of the core GDB team to implement distribute and
test their plugins without modifying GDB.
- lowers the bar to creating modifications to GDB (exposes a well
defined interface, so there's no need to learn the ins and outs of
GDB to write the plugin you need/want)
Scott Moser's idea was to have very basic plugin support (loading and
unloading), and leave to the plugin writer the work of searching which
internal GDB functions he'd need to use and directly call them from the
plugin code. I am more inclined to go into a different direction, which
is to provide an abstraction layer which would expose functionality
which is potentially useful for a plugin.
Each approach has advantages and disadvantages, but some of the
advantages I pointed out above only hold if you have such abstraction
layer.
--
[]'s
Thiago Jung Bauermann
Software Engineer
IBM Linux Technology Center