From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20776 invoked by alias); 22 Dec 2007 14:14:17 -0000 Received: (qmail 20763 invoked by uid 22791); 22 Dec 2007 14:14:16 -0000 X-Spam-Check-By: sourceware.org Received: from sibelius.xs4all.nl (HELO brahms.sibelius.xs4all.nl) (82.92.89.47) by sourceware.org (qpsmtpd/0.31) with ESMTP; Sat, 22 Dec 2007 14:14:10 +0000 Received: from brahms.sibelius.xs4all.nl (kettenis@localhost.sibelius.xs4all.nl [127.0.0.1]) by brahms.sibelius.xs4all.nl (8.14.1/8.14.0) with ESMTP id lBMEE402032345; Sat, 22 Dec 2007 15:14:04 +0100 (CET) Received: (from kettenis@localhost) by brahms.sibelius.xs4all.nl (8.14.1/8.14.1/Submit) id lBMEE3aG000537; Sat, 22 Dec 2007 15:14:03 +0100 (CET) Date: Sat, 22 Dec 2007 14:14:00 -0000 Message-Id: <200712221414.lBMEE3aG000537@brahms.sibelius.xs4all.nl> From: Mark Kettenis To: nick.hudson@dsl.pipex.com CC: gdb@sourceware.org In-reply-to: <200712221317.22469.nick.hudson@dsl.pipex.com> (message from Nick Hudson on Sat, 22 Dec 2007 13:17:21 +0000) Subject: Re: threads and core file support References: <200712221317.22469.nick.hudson@dsl.pipex.com> Mailing-List: contact gdb-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-owner@sourceware.org X-SW-Source: 2007-12/txt/msg00168.txt.bz2 > From: Nick Hudson > Date: Sat, 22 Dec 2007 13:17:21 +0000 > > Hi, > > I'm (slowly) working on improving NetBSD pthreads and core file > support and it appears to me the best (only?) example to follow is > sol-thread.c. That code is old and hasn't been properly maintained for years; I wouldn't recommend using it as a guideline. It also uses libthreads_db, which makes building a cross-debugger almost impossible and complicates matters unecessary for 1:1 threading models. The Linux threading code suffers from the same problem, but is in many respects even worse, because the Linux kernel lacked a proper threads debugging interface for quite a while and the code was written towards an evolving kernel interface. My recommendation is to start working on making GDB aware of LWPs (I think that's how kernel-level threads are called on NetBSD). You'll probably need to write a NetBSD-specific replacement for inf-ptrace.c for that. I recommend looking at inf-ttrace.c for an example on how to handle multiple threads. Then, after that, you might want the add a layer to link LWPs to user-level threads. For a pthreads library that uses a 1:1 threading model this can be as simple as annotating all threads with the pthread_t identifier and changing the way GDB will print thread IDs using that. For N:M threading models things are probably a bit more complicated (but even Solaris is moving away from N:M threading). Cheers, Mark