PERFORCE change 55970 for review

[David Xu]

Marcel Moolenaar wrote:

>On Mon, Jun 28, 2004 at 02:27:08PM +0800, David Xu wrote:
>  
>
>>OK, I am glad to see you are working on libthread_db, but
>>I have already a libthread_db tree in ksedbg branch.
>>    
>>
>
>I know. My focus is different. I don't care so much about libthread_db
>itself at the moment. My focus is on finding the best possible way
>to make it all work with the debugger. This includes core dumps, the
>proc services, ptrace and libthread_db. I need to play around with it
>all to understand what we need to do where and what it is that's being
>provided. Then I know how and what we need to add where.
>
>We may not need a ttrace(2) syscall for example. We can have ptrace(2)
>accept lwpids as well as pids and have it do the right thing. Also, as
>I've told you before, ttrace(2) is not standard, but it's something
>that already exists. We need to decide whether we want to be compatible
>with the HP-UX implementation and to what extend.
>
>  
>
OK, ttrace was existing before lwpid_t was introduced, I will
check if I can reuse ptrace interface.

>I also found ways to preserve compatibility with RELENG_4, so that
>we can use gdb 6.1.1 with libthread_db on 4.x core files. This only
>needs to apply to libc_r of course.
>
>  
>
>>I am current making libthread_db.so in two levels:
>>the first level is a umbrella, the second level is a driver,
>>every thread library will have a driver, I found you were trying
>>to mix three thread libraries code into in same functions,
>>things like following code looks strange for me, how can you
>>include three different thr_pirvate.h in same .c, and compile
>>them ?
>>    
>>
>
>I don't include any private headers. I'm merely taking advantage of
>how the libc_r support was written. See
>src/gnu/usr.bin/binutils/gdb/freebsd-uthread.c
>
>Note that although cross-debugging is not something I'm focussed on,
>I try to avoid depending too much on native (private) headers. This
>at least keeps the option open for as much as possible.
>
>Anyway: I don't care about which libthread_db is eventually going to
>be used. I just need the stuff the play around with.
>
>  
>