From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 18121 invoked by alias); 1 Dec 2008 22:38:04 -0000 Received: (qmail 18109 invoked by uid 22791); 1 Dec 2008 22:38:04 -0000 X-Spam-Check-By: sourceware.org Received: from smtp-outbound-2.vmware.com (HELO smtp-outbound-2.vmware.com) (65.115.85.73) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Mon, 01 Dec 2008 22:37:27 +0000 Received: from mailhost2.vmware.com (mailhost2.vmware.com [10.16.67.167]) by smtp-outbound-2.vmware.com (Postfix) with ESMTP id 7F3DF34006; Mon, 1 Dec 2008 14:37:24 -0800 (PST) Received: from [10.20.92.151] (promb-2s-dhcp151.eng.vmware.com [10.20.92.151]) by mailhost2.vmware.com (Postfix) with ESMTP id 666F58E5D1; Mon, 1 Dec 2008 14:37:24 -0800 (PST) Message-ID: <493466AC.30409@vmware.com> Date: Mon, 01 Dec 2008 22:38:00 -0000 From: Michael Snyder User-Agent: Thunderbird 1.5.0.12 (X11/20080411) MIME-Version: 1.0 To: Pedro Alves CC: "gdb-patches@sourceware.org" Subject: Re: Fix foll-fork.exp foll-vfork.exp fork-child-threads.exp References: <200811201328.13651.pedro@codesourcery.com> <493433D7.7080803@vmware.com> <200812012106.43909.pedro@codesourcery.com> In-Reply-To: <200812012106.43909.pedro@codesourcery.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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/msg00021.txt.bz2 Pedro Alves wrote: > 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. OK, sounds like you've already thought it through then.