Skip site navigation (1)Skip section navigation (2)
Date:      Tue, 29 Jun 2004 07:04:29 +0800
From:      David Xu <davidxu@freebsd.org>
To:        Marcel Moolenaar <marcel@xcllnt.net>
Cc:        Perforce Change Reviews <perforce@freebsd.org>
Subject:   Re: PERFORCE change 55970 for review
Message-ID:  <40E0A3FD.1000804@freebsd.org>
In-Reply-To: <20040628174213.GA51072@dhcp50.pn.xcllnt.net>
References:  <200406280413.i5S4DS0D033867@repoman.freebsd.org> <40DFBA3C.7040806@freebsd.org> <20040628174213.GA51072@dhcp50.pn.xcllnt.net>

next in thread | previous in thread | raw e-mail | index | archive | help
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.
>
>  
>



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?40E0A3FD.1000804>