From: Thiago Jung Bauermann <bauerman@br.ibm.com>
To: gdb ml <gdb@sourceware.org>
Subject: plugin interface for GDB
Date: Fri, 20 Apr 2007 19:44:00 -0000 [thread overview]
Message-ID: <1177098228.20179.10.camel@localhost.localdomain> (raw)
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
next reply other threads:[~2007-04-20 19:44 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2007-04-20 19:44 Thiago Jung Bauermann [this message]
2007-04-20 19:57 ` Brian Dessent
2007-04-20 21:39 ` Thiago Jung Bauermann
2007-04-20 20:00 ` Daniel Jacobowitz
2007-04-20 21:21 ` Thiago Jung Bauermann
2007-04-20 21:55 ` Daniel Jacobowitz
2007-04-20 22:01 ` Paul Koning
2007-04-20 23:00 ` Robert Dewar
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1177098228.20179.10.camel@localhost.localdomain \
--to=bauerman@br.ibm.com \
--cc=gdb@sourceware.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox