From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21202 invoked by alias); 5 Jun 2014 18:34:27 -0000 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 Received: (qmail 21181 invoked by uid 89); 5 Jun 2014 18:34:27 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.7 required=5.0 tests=AWL,BAYES_00 autolearn=ham version=3.3.2 X-HELO: relay1.mentorg.com Received: from relay1.mentorg.com (HELO relay1.mentorg.com) (192.94.38.131) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 05 Jun 2014 18:34:25 +0000 Received: from svr-orw-exc-10.mgc.mentorg.com ([147.34.98.58]) by relay1.mentorg.com with esmtp id 1WscUX-0007JP-5h from donb@codesourcery.com ; Thu, 05 Jun 2014 11:34:21 -0700 Received: from [127.0.0.1] ([172.30.4.134]) by SVR-ORW-EXC-10.mgc.mentorg.com with Microsoft SMTPSVC(6.0.3790.4675); Thu, 5 Jun 2014 11:34:20 -0700 Message-ID: <5390B82C.6010807@codesourcery.com> Date: Thu, 05 Jun 2014 18:34:00 -0000 From: "Breazeal, Don" User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 To: Pedro Alves , gdb-patches@sourceware.org Subject: Re: [PATCH] Fix for follow-fork: followed child doesn't stop References: <1401920383-10219-1-git-send-email-donb@codesourcery.com> <53906804.3070107@redhat.com> In-Reply-To: <53906804.3070107@redhat.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2014-06/txt/msg00281.txt.bz2 Hi Pedro, Thanks for looking at this. On 6/5/2014 5:52 AM, Pedro Alves wrote: > Hi Don, > > On 06/04/2014 11:19 PM, Don Breazeal wrote: >> Using the test program gdb.base/foll-fork.c, with follow-fork-mode >> set to "child" and detach-on-fork set to "on", stepping past the >> fork call results in the child process running to completion, when >> it should just finish the single step. >> >> This is the result of how the single-step state is transferred from >> the parent to the child in infrun.c:follow_fork. For the parent, the >> single-step breakpoint is marked as "inserted" (bp->loc->inserted). > >> The breakpoint is transferred to the child, where it clearly has never >> been inserted. > > Was it removed from the parent already at this point? If so, > why is it still marked as inserted? If not, then it would sound > like your patch would make us miss removing it. > Yes, by the time the 'inserted' flag is cleared, the breakpoint has been removed from the parent. The flag is set because the child's breakpoint is a clone of the parent's breakpoint that was created before the parent's breakpoint was removed. The step-resume breakpoint is cloned from the parent's copy earlier in the function, bringing the value of the 'inserted' flag along with it. Then the parent's breakpoint is deleted, with the side-effect of removing it. >From infrun.c:follow_fork: [...here 'tp' is the parent thread...] if (follow_child && should_resume) { step_resume_breakpoint = clone_momentary_breakpoint (tp->control.step_resume_breakpoint); [...] delete_step_resume_breakpoint (tp); [...here bkpt has been removed from the parent...] } [...calls target_follow_fork...] /* If we followed the child, switch to it... */ if (follow_child) { switch_to_thread (child); /* ... and preserve the stepping state, in case the user was stepping over the fork call. */ if (should_resume) { tp = inferior_thread (); tp->control.step_resume_breakpoint = step_resume_breakpoint; [...this only affects the child process...] if (tp->control.step_resume_breakpoint != NULL) tp->control.step_resume_breakpoint->loc->inserted = 0; Does that explanation make sense? Luis suggests adding a comment that explains why the flag is cleared. Would that be sufficient? Thanks --Don