cvs commit: src/lib/libpthread_dbg Makefile
pthread_dbg.cpthread_dbg.h
src/lib/libpthread_dbg/arch/i386/i386 pthread_dbg_md.c
David Xu
davidxu at freebsd.org
Wed Feb 4 17:07:14 PST 2004
Daniel Eischen wrote:
>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.
>
>
I will make libkse work with gdb, but won't do such work, because I
won't have so
much free time, I am busy at work due to job transfer.
David Xu
More information about the cvs-src
mailing list