From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5454 invoked by alias); 8 Aug 2008 22:42:13 -0000 Received: (qmail 5442 invoked by uid 22791); 8 Aug 2008 22:42:11 -0000 X-Spam-Check-By: sourceware.org Received: from mail.codesourcery.com (HELO mail.codesourcery.com) (65.74.133.4) by sourceware.org (qpsmtpd/0.31) with ESMTP; Fri, 08 Aug 2008 22:41:37 +0000 Received: (qmail 13060 invoked from network); 8 Aug 2008 22:41:34 -0000 Received: from unknown (HELO orlando.local) (pedro@127.0.0.2) by mail.codesourcery.com with ESMTPA; 8 Aug 2008 22:41:34 -0000 From: Pedro Alves To: Mark Kettenis Subject: Re: [3/7] Adjust the bsd-uthread target Date: Fri, 08 Aug 2008 22:42:00 -0000 User-Agent: KMail/1.9.9 Cc: gdb-patches@sourceware.org References: <200808080236.04076.pedro@codesourcery.com> <200808082151.m78LpP2T028239@brahms.sibelius.xs4all.nl> In-Reply-To: <200808082151.m78LpP2T028239@brahms.sibelius.xs4all.nl> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200808082341.23994.pedro@codesourcery.com> X-IsSubscribed: yes Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2008-08/txt/msg00226.txt.bz2 A Friday 08 August 2008 22:51:25, Mark Kettenis escreveu: > > From: Pedro Alves > > Date: Fri, 8 Aug 2008 02:36:03 +0100 > > > > This patch adjusts the bsd-uthread target to use thread_change_ptid, > > and to never let the core see an event happen in a thread not in > > the thread table. > > > > Tested on i386-unknown-freebsd6.0 with a little hack in the > > testsuite to link the gdb.thread tests against -lc_r instead > > of -lpthread, and on i386-unknown-openbsd4.3, where no hack is > > needed. > > > > This patch depends on patch 1 and 2. > > > > OK? > > > > Index: src/gdb/bsd-uthread.c > > =================================================================== > > --- src.orig/gdb/bsd-uthread.c 2008-07-29 12:06:38.000000000 +0100 > > +++ src/gdb/bsd-uthread.c 2008-07-29 12:17:34.000000000 +0100 > > @@ -413,7 +415,7 @@ bsd_uthread_find_new_threads (void) > > { > > ptid_t ptid = ptid_build (pid, 0, addr); > > > > - if (!in_thread_list (ptid)) > > + if (!in_thread_list (ptid) || is_exited (ptid)) > > add_thread (ptid); > > This doesn't make sense to me. You're adding a threadhere that's no > longer there? The "exited" state is what you get *after* you delete_thread the current thread (inferior_ptid). We don't delete the thread from the thread list in that case, but instead tag it as "exited". It means the thread list is still holding reference to a thread that has already exited. If you're seeing an event with a ptid equal to an "exited" thread, this is the OS reusing the ptid, but, it's a new thread, which should get a new gdb thread id, so things like thread specific breakpoints don't think this was the same thread, both the CLI user or MI see a "new thread event", etc. add_thread handles that case internally. This means it is now safe to delete_thread (inferior_ptid), regarding context-switching, and infrun state. It wasn't a couple of weeks ago. -- Pedro Alves