This is the mail archive of the
gdb-patches@sources.redhat.com
mailing list for the GDB project.
Re: [PATCH] plugin patch
- From: Klee Dienes <klee at apple dot com>
- To: "Paul A. Clarke" <pac at us dot ibm dot com>
- Cc: Andrew Cagney <ac131313 at redhat dot com>,Scott Moser <ssmoser at us dot ibm dot com>,Jelmer Vernooij <jelmer at samba dot org>,Eli Zaretskii <eliz at is dot elta dot co dot il>,gdb-patches at sources dot redhat dot com
- Date: Thu, 7 Nov 2002 16:10:43 -0500
- Subject: Re: [PATCH] plugin patch
We've also been using our own version of GDB plug-ins at Apple, and
have found them to be rather handy at times. Three examples of places
where plug-ins have been used:
* While doing performance analysis, I wrote a 100-line plug-in that
hooks up GDB to a Mac OS X-specific performance monitoring library.
The change is OSX-specific and uses Objective-C, and there's just about
zero chance it would ever be appropriate for the main-line GDB sources,
nor do I want it cluttering up our local branch when I'm not using it.
But as a plug-in, I can just load it into my GDB when I need it for
performance analysis.
* Our kernel developers sometimes find themselves dumping insanely
nasty structures that can take quite a while to print using the core
GDB. GDB plug-ins let them write custom viewers/dumpers (typically 10x
or more faster) without going through the hassle of maintaining a GDB
tree or keeping custom binaries around.
* One of my crazy co-workers wrote a complete MacsBug front-end to GDB
as a plug-in as a "nights and weekends" project. This isn't something
that we want to support in our core GDB sources, nor is it something
I'd really expect the FSF folks to be particularly interested in
picking up. But it was a really cool hack, and one that was developed
completely independently of our core GDB work.
On Thursday, November 7, 2002, at 01:02 PM, Paul A. Clarke wrote:
- Scott started working on a GDB plug-in for libgtk, which would allow
a
developer to 'somehow' highlight certain widgets on demand, given a
widget's handle
- a similar GDB plug-in for libGL, which can track the OpenGL state
machine and validate calls as they are made
- a GDB plug-in which can trace calls to a given API, with knowlege
about parameter types and ranges
- a potentially large plug-in for GDB which can make use of
processor-specific performance monitoring capabilities
- a potentially large plug-in for GDB which does really goofy things to
the inferior like code surgery or error correction on-the-fly
(No, I don't have examples of these. Yet! I wish I did.) It didn't
take too much brainstorming to come up with what (I hope) are decent
examples where plug-in/module support would be useful (you wouldn't
want
to integrate all of those into GDB, would you?) and would accelerate
the
advancement of GDB into new and broader areas, and all code would
necessarily be GPL'd.
Regards (and thanks for your patience and attention!),
Paul Clarke