From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6069 invoked by alias); 1 Sep 2010 16:56:54 -0000 Received: (qmail 6061 invoked by uid 22791); 1 Sep 2010 16:56:53 -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, 01 Sep 2010 16:56:48 +0000 Received: (qmail 19134 invoked from network); 1 Sep 2010 16:56:47 -0000 Received: from unknown (HELO ?192.168.0.101?) (yao@127.0.0.2) by mail.codesourcery.com with ESMTPA; 1 Sep 2010 16:56:47 -0000 Message-ID: <4C7E85C0.3050902@codesourcery.com> Date: Wed, 01 Sep 2010 16:56:00 -0000 From: Yao Qi User-Agent: Thunderbird 2.0.0.24 (X11/20100411) MIME-Version: 1.0 To: gdb-patches@sourceware.org Subject: [PATCH,ARM] Fix single step on vfork Content-Type: multipart/mixed; boundary="------------000001060701030308000507" 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/msg00022.txt.bz2 This is a multi-part message in MIME format. --------------000001060701030308000507 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-length: 719 Hi, Recently, we find some failures in gdb testsute on ARM, FAIL: gdb.base/watch-vfork.exp: Watchpoint triggers after vfork (hw) (the program exited) FAIL: gdb.base/watch-vfork.exp: Watchpoint triggers after vfork (sw) (the program exited) Program exits when we stepping over svc instruction in vfork(), which is caused by child process hits software single step breakpoint inserted for parent process. This patch is to fix this problem by 'when inferior's wait_for_vfork_done is true, clear step to zero and don't use displaced stepping'. Tested on GDB CVS on ARM and X86-64. Fix these two failures above on ARM, and no regressions. OK to apply? -- Yao Qi CodeSourcery yao@codesourcery.com (650) 331-3385 x739 --------------000001060701030308000507 Content-Type: text/x-patch; name="single_step_vfork_1.patch" Content-Transfer-Encoding: 7bit Content-Disposition: inline; filename="single_step_vfork_1.patch" Content-length: 1858 2010-09-02 Yao Qi * infrunc(resume): When inferior is waiting_for_vfork_done, clear step and don't use displaced stepping. diff --git a/gdb/infrun.c b/gdb/infrun.c index dd89e78..2f28380 100644 --- a/gdb/infrun.c +++ b/gdb/infrun.c @@ -1550,6 +1550,19 @@ resume (int step, enum target_signal sig) QUIT; + /* Don't consider single-stepping when the inferior is + waiting_for_vfork_done, either software or hardware step. In + software step, child process will hit the software single step + breakpoint inserted in parent process. In hardware step, GDB + can resumes inferior, and waiting for vfork_done event. */ + 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), " @@ -1577,11 +1590,16 @@ a command like `return' or `jump' to continue execution.")); 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; --------------000001060701030308000507--