cvs commit: src/lib/libpthread_dbg Makefile
eischen at vigrid.com
Wed Feb 4 09:53:04 PST 2004
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
> 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?).
More information about the cvs-all