From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24754 invoked by alias); 10 Mar 2006 20:16:16 -0000 Received: (qmail 24746 invoked by uid 22791); 10 Mar 2006 20:16:16 -0000 X-Spam-Check-By: sourceware.org Received: from mx1.redhat.com (HELO mx1.redhat.com) (66.187.233.31) by sourceware.org (qpsmtpd/0.31) with ESMTP; Fri, 10 Mar 2006 20:16:14 +0000 Received: from int-mx1.corp.redhat.com (int-mx1.corp.redhat.com [172.16.52.254]) by mx1.redhat.com (8.12.11/8.12.11) with ESMTP id k2AKGBFs019992 for ; Fri, 10 Mar 2006 15:16:11 -0500 Received: from potter.sfbay.redhat.com (potter.sfbay.redhat.com [172.16.27.15]) by int-mx1.corp.redhat.com (8.11.6/8.11.6) with ESMTP id k2AKGA109734; Fri, 10 Mar 2006 15:16:10 -0500 Received: from [172.16.24.50] (bluegiant.sfbay.redhat.com [172.16.24.50]) by potter.sfbay.redhat.com (8.12.8/8.12.8) with ESMTP id k2AKG8mG021639; Fri, 10 Mar 2006 15:16:09 -0500 Message-ID: <4411DE88.1080105@redhat.com> Date: Sat, 11 Mar 2006 19:08:00 -0000 From: Michael Snyder User-Agent: Mozilla Thunderbird 1.0.7-1.4.1 (X11/20050929) MIME-Version: 1.0 To: Daniel Jacobowitz CC: GDB Patches , Randolph Chung Subject: Re: [RFA] linux multi-fork kill (re: "run", and executable file/symtab association?) References: <4410D0AC.1000505@redhat.com> <20060310200839.GA30634@nevyn.them.org> In-Reply-To: <20060310200839.GA30634@nevyn.them.org> 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-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2006-03/txt/msg00169.txt.bz2 Daniel Jacobowitz wrote: > On Thu, Mar 09, 2006 at 05:04:44PM -0800, Michael Snyder wrote: > >>Randolph, this is in response to your bug report. >>Daniel, see if this looks OK to you. Instead of calling >>pop_target (which, I agree, was iffy), we just go thru >>target_mourn_inferior like we always did. >> >>Rearranged linux_fork_killall because of an unexpected >>interaction with delete_fork -- at least one fork wasn't >>getting killed, because delete_fork tries to be too clever. > > > Looks good to me. You're right, I'll need to re-merge - how about > you go first since I don't know when I'll have a chance to update > that patch? > Committed.