Re: [RFC] plugin/extension interface

[Jim Blandy <jimb@red-bean.com>]

I'm not so hostile to plug-in interfaces.  It's true that the API
needs to be designed carefully, but allowing people to maintain other
features (targets; architectures; commands) separately from GDB would
take a big load off our backs.

It's true that plugin interfaces weaken the incentives the GPL tries
to create, but while I think that was very important even five years
ago, I don't think that's such a big deal any more.  Maybe I don't get
out enough, but I think there's already a consensus building that Open
Source is simply the preferable way to develop programmers' tools, and
most companies are just doing it freely, not because they have to use
GPL'd ode.

libthread_db has been a debacle, but I'd argue that's because it was
designed for Solaris, and we lacked the option of adjusting the
interface to better suit other systems.  For example, the API doesn't
abstract the process of stopping or continuing threads, meaning that
it doesn't have the information it needs to cache things accurately in
some cases (leading to bad performance) and that GDB pays the price in
complexity of supporting the plugin interface, but ends up knowing a
lot about the thread implementation anyway, so it doesn't get much
benefit.