This is the mail archive of the gdb@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]