From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 22711 invoked by alias); 8 Sep 2010 12:26:23 -0000 Received: (qmail 22698 invoked by uid 22791); 8 Sep 2010 12:26:21 -0000 X-SWARE-Spam-Status: No, hits=-1.9 required=5.0 tests=AWL,BAYES_00,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Received: from mail.codesourcery.com (HELO mail.codesourcery.com) (38.113.113.100) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 08 Sep 2010 12:26:15 +0000 Received: (qmail 31855 invoked from network); 8 Sep 2010 12:26:13 -0000 Received: from unknown (HELO ?192.168.0.100?) (yao@127.0.0.2) by mail.codesourcery.com with ESMTPA; 8 Sep 2010 12:26:13 -0000 Message-ID: <4C8780D7.4040709@codesourcery.com> Date: Wed, 08 Sep 2010 17:23:00 -0000 From: Yao Qi User-Agent: Thunderbird 2.0.0.24 (X11/20100411) MIME-Version: 1.0 To: Pedro Alves CC: gdb-patches@sourceware.org Subject: Re: [PATCH,ARM] Fix single step on vfork References: <4C7E85C0.3050902@codesourcery.com> <201009061257.20113.pedro@codesourcery.com> <4C84ECB9.8040601@codesourcery.com> <201009061524.54659.pedro@codesourcery.com> In-Reply-To: <201009061524.54659.pedro@codesourcery.com> Content-Type: multipart/mixed; boundary="------------030108020003050308030805" 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: 2010-09/txt/msg00177.txt.bz2 This is a multi-part message in MIME format. --------------030108020003050308030805 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit Content-length: 647 Pedro Alves wrote: > On Monday 06 September 2010 14:29:29, Yao Qi wrote: >> Pedro Alves wrote: >>> Thanks. Please go ahead with your patch. Hope you don't mind I tweak >>> the comment a bit afterwards. >>> >> Pedro, >> Thanks for your view, and free to tweak the comment. >> >> Committed to GDB mainline, >> http://www.cygwin.com/ml/gdb-cvs/2010-09/msg00042.html >> >> Once you changed the comment, I'd like to merge it to GDB 7.2 branch then. > > Okay. I've now applied this to mainline. Committed it to GDB 7.2 branch. http://www.cygwin.com/ml/gdb-cvs/2010-09/msg00054.html -- Yao Qi CodeSourcery yao@codesourcery.com (650) 331-3385 x739 --------------030108020003050308030805 Content-Type: text/x-patch; name="single_step_vfork.patch" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="single_step_vfork.patch" Content-length: 2408 Index: infrun.c 2010-09-08 Yao Qi Pedro Alves * infrunc(resume): When inferior is waiting_for_vfork_done, clear step and don't use displaced stepping. Extend comment on ignoring single-step requests on vfork parents waiting for a vfork-done. =================================================================== RCS file: /cvs/src/src/gdb/infrun.c,v retrieving revision 1.445.2.1 diff -u -r1.445.2.1 infrun.c --- infrun.c 31 Aug 2010 19:31:23 -0000 1.445.2.1 +++ infrun.c 8 Sep 2010 12:16:17 -0000 @@ -1549,6 +1549,25 @@ QUIT; + /* Don't try to single-step a vfork parent that is waiting for + the child to get out of the shared memory region (by exec'ing + or exiting). This is particularly important on software + single-step archs, as the child process would trip on the + software single step breakpoint inserted for the parent + process. Since the parent will not actually execute any + instruction until the child is out of the shared region (such + are vfork's semantics), it is safe to simply continue it. + Eventually, we'll see a TARGET_WAITKIND_VFORK_DONE event for + the parent, and tell it to `keep_going', which automatically + re-sets it stepping. */ + if (current_inferior ()->waiting_for_vfork_done) + { + if (debug_infrun) + fprintf_unfiltered (gdb_stdlog, + "infrun: resume : clear step\n"); + step = 0; + } + if (debug_infrun) fprintf_unfiltered (gdb_stdlog, "infrun: resume (step=%d, signal=%d), " @@ -1576,11 +1595,16 @@ We can't use displaced stepping when we have a signal to deliver; the comments for displaced_step_prepare explain why. The comments in the handle_inferior event for dealing with 'random - signals' explain what we do instead. */ + signals' explain what we do instead. + + We can't use displaced stepping when we are waiting for vfork_done + event, displaced stepping breaks the vfork child similarly as single + step software breakpoint. */ if (use_displaced_stepping (gdbarch) && (tp->trap_expected || (step && gdbarch_software_single_step_p (gdbarch))) - && sig == TARGET_SIGNAL_0) + && sig == TARGET_SIGNAL_0 + && !current_inferior ()->waiting_for_vfork_done) { struct displaced_step_inferior_state *displaced; --------------030108020003050308030805--