Re: [PATCH] plugin patch

["Paul A. Clarke" <pac at us dot ibm dot com>]

...a bit long, sorry...

On Wed, 2002-11-06 at 11:14, Andrew Cagney wrote:
> > Plugins won't "know" the API that is used in newer versions of GDB,
so
> > they can't really decide whether they are or are not compatible with
> > it. Only allowing plugins to be loaded with _exactly_ the same
version 
> > as the gdb they are loaded into works well (same way the linux
kernel
> > does).
 
> [...]  A plug-in architecture only works when there 
> is a stable published interface and GDB's current internal interfaces 
> and mechanisms are about as far from `stable' and `published' as you
can 
> get :-/
> 
> Accepting this patch will create a situtation (actually very like the 
> Linux kernel) where either:
> - The plug-in developers play constant catch-up with GDB's evolving 
> interfaces - every new release will require new plug-in.
> - GDB's development stagnates because the plug-in developers depand
the 
> specification and support of an additional external interface (over
and 
> above MI(2)).

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.

Additionally, if the plug-in is considered generally useful, it could
always be pulled into the GDB base at any time (assuming copyright
ass't.), since we believe all GDB
plug-ins would necessarily be GPL'd.

The pros, then:
- maintenance of plug-in (playing catch-up) is the responsibility of the
plug-in maintainer, not the GDB team
- maintains code size of base GDB
- allows potentially large optional features without bloating GDB
- allows extensibility without requiring GDB source downloads, builds,
or frequent relinks
- arguably encourages innovation by allowing more flexibility in working
with and enhancing GDB
- the enabling patch itself is very small and isolated

The biggest con, then, is the lack of a stable interface.  As you say,
this is also a con for the Linux kernel.  However, it would be no worse
than the Linux kernel, and one could argue that the benefits with
respect to innovation far outweigh revisting a decision to allow them
(kernel modules) in the first place.

If there is any way to make the plug-in capability more palatable, we
can make those changes.  Perhaps each time a plug-in is loaded, a
warning is displayed, like "Plug-ins are not officially supported, so
please report *any* problems to the plug-in maintainer", and encourage
the plug-ins to advertise a maintainer URL.

Maybe instead of "plug-ins", from which some might infer a stable
plug-in API, we should use the term "modules", with similar
non-guarantees of API stability as with the Linux kernel??  :-)

> With regard to the modules that IBM and other vendors are planning on 
> writing, can I encourage you to contribute them to the FSF?  That way,
> the entire Free Software Community would benefit (and this plug-in
issue 
> would be mute :-).

Absolutely, any plug-ins developed for GDB should and will be GPL'd.

> GDB's internals are undergoing massive change(1) and the various GDB 
> interfaces reflect this.
> (1) Don't believe me?  I'm currently commiting patches that eliminates
> registers[] from the core of GDB.  That interface, for too many many 
> years, formed part of the foundation on which GDB was built.

This would seem at least in part to conflict with later comment:

> GDB's current architecture allows the relatively easy addition of new 
> components (a new language, a new remote backend, a new isa) - add the
> file to the source list and re-compile.  In theory, you don't need to
go 
> around modifying lots of headers and the like.
> 
> This is simply ``good design''.

If it is easy to add new components, would it be so hard to maintain a
plug-in?

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

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.

This example is not large enough or niche enough to be a good example of
why plug-ins are a Good Thing, but one can easily see a similar plugin
with library-specific (e.g. libgtk, libqt, etc.) functionality that
probably wouldn't make sense to integrate directly into GDB.  Such a
plug-in could potentially be very large as well.

It's impractical to write something that sends commands to gdb over a
pipe for each such case where a plug-in would be useful, especially if
you need more than one similar case active simultaneously; it's not
acceptable to tell customers to go download GDB, apply a patch, and
build in order to get some neat functionality; and it's not reasonable
to expect that all potential plug-ins are good candidates for inclusion
in the GDB base.  Let each plug-in maintainer handle that work.  As you
said, "there is always more work to do."  :)  

Regards,
Paul Clarke