This is the mail archive of the
gdb-patches@sources.redhat.com
mailing list for the GDB project.
Re: [PATCH] plugin patch
I agree that the above cons are reasonable expectations, but it would
seem the same issues would arise regardless if the code is a plug-in or
just code which is bolted on and rebuilt every time. The maintenance
issues are the same. Indeed, if some bolted-on code is pulled into the
GDB base, then the GDB team become obligated to either maintain it
enough to get a successful build, or remove it entirely. At least with
a plug-in, the maintenance of the plug-in is the responsibility of the
maintainter of the plug-in, not the GDB team.
If someone contributes a new module to GDB then, most likely, the
contributor will become the maintainer - both the GDB user community and
the GDB developer community benefit.
(2) A long term MI objective is to define a set of interfaces that
both
MI and the CLI can use. FernandoN made reference to this in responce
to
your original post.
That's interesting, and I haven't heard about this before. It sounds
like these interfaces would then also be good candidates for a plug-in
interface. Would you agree? Maybe we could help?
Per my other reply, this is simply ``good design'.
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?
Andrew