cvs commit: src/lib/libpthread_dbg Makefile pthread_dbg.cMakefile.inc src/lib/libpthread_dbg/arch/i386/i386 pthread_dbg_md.c

[Daniel Eischen]

On Wed, 4 Feb 2004, Marcel Moolenaar wrote:

> On Wed, Feb 04, 2004 at 04:51:07PM +0800, David Xu wrote:
> > Marcel Moolenaar wrote:
> > 
> > >> Added files:
> > >>   lib/libpthread_dbg   Makefile pthread_dbg.c pthread_dbg.h 
> > >>                        pthread_dbg_int.h 
> > >>   lib/libpthread_dbg/arch/i386 Makefile.inc 
> > >>   lib/libpthread_dbg/arch/i386/i386 pthread_dbg_md.c 
> > >> Log:
> > >> Import initial work of libpthread debugging. This is a debugger 
> > >> independent
> > >> friend library for libpthread, the library will be used by debugger to
> > >> read/write libpthread's internal data structures.
> > >
> > >Euh, the name of the library should be libthread_db. There's not
> > >much point in being gratuitously non-conformant.
> > >
> > OK, but what's libthread_db for ? for libpthread or for libthr and libc_r ?
> 
> All three. The whole point of having libthread_db is to abstract the
> internals of the threading implementation from whatever client needs
> to know more about threads -- like a debugger.
> 
> > I won't write debug code for other thread libraries, and also dislike 
> > mixing other
> > thread library's debug code into the library. I think  the name should 
> > be libpthread_dbg,
> > or libpthread_db.
> 
> I see. You think we should implement the support in gdb(1) then? This
> boils down to adding 3 new (non-conformant) implementations, bringing
> the total to 4:
> 1. libpthread_dbg for KSE on FreeBSD
> 2. Our threading hooks for libc_r on FreeBSD
> 3. Something else (libthr_gdb?) for libthr on FreeBSD
> 4. (unused) the already present, support for the adopted libthread_db
>    interface.
> 
> I'm sure the gdb(1) people are happy with our contribution :-)
> 
> Seriously: We (=FreeBSD) provide 3 threading libraries (2 on ia64).
> It's our problem. I'm fine with you bootstrapping libthread_db with
> only the support for KSE, but eventually libthr needs to be added.

I tend to agree.  From the outside looking in, it would seem
easy enough to allow all 3 thread libraries to be supported.
I think once we have it working with libpthread, we can move
stuff around inside the debug library and one more layer of
abstraction so libthr/libc_r support could be added.

> The support for libc_r is less important as I think libc_r is slated
> to be ripped out anyway (right?). 

:-)

-- 
Dan Eischen