From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29095 invoked by alias); 11 Aug 2008 13:33:30 -0000 Received: (qmail 29064 invoked by uid 22791); 11 Aug 2008 13:33:29 -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; Mon, 11 Aug 2008 13:32:54 +0000 Received: (qmail 4584 invoked from network); 11 Aug 2008 13:32:53 -0000 Received: from unknown (HELO orlando.local) (pedro@127.0.0.2) by mail.codesourcery.com with ESMTPA; 11 Aug 2008 13:32:53 -0000 From: Pedro Alves To: Daniel Jacobowitz Subject: Re: [3/7] Adjust the bsd-uthread target Date: Mon, 11 Aug 2008 13:33:00 -0000 User-Agent: KMail/1.9.9 Cc: Mark Kettenis , gdb-patches@sourceware.org References: <200808080236.04076.pedro@codesourcery.com> <200808082341.23994.pedro@codesourcery.com> <20080809013130.GA28372@caradoc.them.org> In-Reply-To: <20080809013130.GA28372@caradoc.them.org> MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200808111432.50086.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/msg00294.txt.bz2 On Saturday 09 August 2008 02:31:30, Daniel Jacobowitz wrote: > On Fri, Aug 08, 2008 at 11:41:23PM +0100, Pedro Alves wrote: > > 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. > How many of the call sites for in_thread_list want to see exited > threads? Maybe there should be another predicate (I'd suggest > thread_alive except target_thread_alive would confuse things...) I actually started out using a new predicate, but then got rid of it, as it looked more confusing to me. There are a few calls than want to see all threads. context_switch (while it still exists :-) ) and handle_inferior_event want to. The breakpoints.c and infcmd.c calls don't care currently. Can I ask you to not do that now, please? I can come back to it as an follow-up cleanup. I've got several patches that touch contexts where this form was used, and it would be a lot of work to rebase and retest them all for not much gain. A single patch to cleanup and introduce a new predicate can be made in one sweep. -- Pedro Alves