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]

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