Date: Wed, 4 Feb 2004 12:53:01 -0500 (EST) From: Daniel Eischen <eischen@vigrid.com> To: Marcel Moolenaar <marcel@xcllnt.net> Cc: cvs-all@FreeBSD.org Subject: Re: cvs commit: src/lib/libpthread_dbg Makefile pthread_dbg.cMakefile.inc src/lib/libpthread_dbg/arch/i386/i386 pthread_dbg_md.c Message-ID: <Pine.GSO.4.10.10402041250081.25474-100000@pcnet5.pcnet.com> In-Reply-To: <20040204173020.GA46046@ns1.xcllnt.net>
next in thread | previous in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.GSO.4.10.10402041250081.25474-100000>