Re: [RFC] plugin/extension interface

[Mark Kettenis <mark.kettenis@xs4all.nl>]

> Date: Fri, 2 Dec 2005 14:12:46 -0800
> From: 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.

I really doubt that.  Short term it'd only increase the load since we
have to build the plug-in interface.  Long term, we still have to
maintain that interface.  We'll also get lots of support questions
where the problems are really with the third party plugins, but where
the bug reporter conveniently forgets to mention that he's using a
third party plugin.  Let's keep people out of our address space if
they don't want to commit themselves to providing sources and manpower
to maintain those sources.

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

Never really realised it, but actually all that we use libthread_db
for is mapping process IDs into use-level thread IDs.  Suddenly HP's
ttrace(2) interface makes sense to me; they have a field to store the
user-level thread ID in the kernel.  That way you really don't need
any knwoledge about the threads implementation at all, except that
there's a 1:1 mapping between LWPs and user-level threads.

What I meant by the libthread_db debacle is the fact that gdb picks up
the wrong version of it sometimes and that this makes things fail in
nonobvious ways.  Not the fact that trying to support several
different kernels and threads libraries, most of which have serious
bugs, is really erh... difficult.

Mark