This is the mail archive of the gdb-patches@sources.redhat.com 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]

Re: [PATCH] plugin patch


On Wed, 2002-11-06 at 17:56, Andrew Cagney wrote:
> > Just as an example, using Scott's plug-in enabling patch, I created a
> > plug-in which detects memory leaks and bad calls to free (any address
> > not previously returned by an allocation function).  (I'd be happy to
> > share it with the list if anyone is interested.)  One can
> > enable/suspend/resume/disable the detection logic at any time, and a
> > full report, including full backtraces is available.
> 
> Cool!  Can you contribute it to the FSF so that it can be integrated 
> into GDB?

I'd love to!  The only issues, aside from paperwork, are:

- it's based on Scott's plug-in enablement patch
- it currently only works on x86 (tested on GNU/Linux)

This last point leads into my next pitch for plug-in support (you had to
expect it, right?  ;-)

Would you consider the following as valid reasons for supporting
optional functionality via a dynamically-loaded plug-in/module
mechanism?
- generally useful function which isn't yet ported to multiple
architectures
- useful function, but only to a niche audience
- useful function, but of significant size, large enough to warrant only
building and/or loading it when desired

For example, as I mentioned previously, function which has apriori
knowledge of specific libraries/APIs, or function which is very
architecture-specific.  Specific examples are numerous, and include:

- 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


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