From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16767 invoked by alias); 1 Dec 2008 21:06:49 -0000 Received: (qmail 16759 invoked by uid 22791); 1 Dec 2008 21:06:49 -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.43rc1) with ESMTP; Mon, 01 Dec 2008 21:06:14 +0000 Received: (qmail 18993 invoked from network); 1 Dec 2008 21:06:11 -0000 Received: from unknown (HELO orlando.local) (pedro@127.0.0.2) by mail.codesourcery.com with ESMTPA; 1 Dec 2008 21:06:11 -0000 From: Pedro Alves To: Michael Snyder Subject: Re: Fix foll-fork.exp foll-vfork.exp fork-child-threads.exp Date: Mon, 01 Dec 2008 21:06:00 -0000 User-Agent: KMail/1.9.10 Cc: "gdb-patches@sourceware.org" References: <200811201328.13651.pedro@codesourcery.com> <493433D7.7080803@vmware.com> In-Reply-To: <493433D7.7080803@vmware.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200812012106.43909.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-12/txt/msg00012.txt.bz2 On Monday 01 December 2008 18:58:31, Michael Snyder wrote: > I'm not sure if this change goes far enough. This patch restored the same behaviour to what happened when GDB still used context-switching. No more, no less. When you had context-switching, no matter which side of the fork you followed, the current infrun context would have been left to the thread that ended up being set as current. Without it, you have to refetch a new pointer to the current thread, as it may be a different thread that it was on entry. > If a multi-threaded program forks, only the currently > executing thread survives in the child. > All others are > left behind (and its not unlikely that the thread library > is left in an inconsistant state, possibly leading to > deadlocks). You mean 'not unlikely' in thread library implementations in several targets, or 'not unlikely' in current glibc/ntpl implementations? glibc is supposed to handle that gracefully. > > We can't do anything about that, but we could, eg., > invalidate all known debugger state having to do with > other threads. Clear the gdb thread list and preserve > only the current thread. The new fork *is* considered a new inferior, and starts with only one thread listed. In mainline, linux_nat_switch_fork always clears the thread list and adds a new thread. In a true multi-process linux native implementation (which can leave GDB attached to both parent and child, and have them running simultaneously (*)), we'd still want to consider the child fork a new single-threaded inferior, and defer to thread_db to find the thread's thread_db id (and eventually, any other thread, in the child in case that changes in the future). Other targets may behave differently, so this is target side concern. (*) - I'm working some on that. -- Pedro Alves