[PATCH] plugin patch

[Klee Dienes]

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
>