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

[Marcel Moolenaar]

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.
The support for libc_r is less important as I think libc_r is slated
to be ripped out anyway (right?). 

-- 
 Marcel Moolenaar	  USPA: A-39004		 marcel at xcllnt.net