Re: [PATCH] plugin patch

[Andrew Cagney <ac131313@redhat.com>]

> 
> 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