From patchwork Tue Jun 14 11:16:53 2016 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Yao Qi X-Patchwork-Id: 13061 Received: (qmail 47589 invoked by alias); 14 Jun 2016 11:17:16 -0000 Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org Delivered-To: mailing list gdb-patches@sourceware.org Received: (qmail 47567 invoked by uid 89); 14 Jun 2016 11:17:15 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.6 required=5.0 tests=AWL, BAYES_00, FREEMAIL_FROM, RCVD_IN_DNSWL_LOW, SPF_PASS autolearn=ham version=3.3.2 spammy=197, 8, HX-Received:10.66.157.193 X-HELO: mail-pa0-f67.google.com Received: from mail-pa0-f67.google.com (HELO mail-pa0-f67.google.com) (209.85.220.67) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-GCM-SHA256 encrypted) ESMTPS; Tue, 14 Jun 2016 11:17:05 +0000 Received: by mail-pa0-f67.google.com with SMTP id fg1so12500362pad.3 for ; Tue, 14 Jun 2016 04:17:04 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:cc:subject:references:date:in-reply-to :message-id:user-agent:mime-version:content-transfer-encoding; bh=aYfiMJ15hhiRtPwFqjnbg9jHTQBTIWJ6G58zZk5gm+0=; b=fFtKRHba9eQMZpTwIxbJ+WQz+RM714dc7ZX+QFbi2CSBXSs64sRrgMNKU/p9tXFJJR 9s+zRdzKi1vataF6wEBhL/kio+T38VCwWcFgUJgfUtnOR+VRV9YA0MnrNC6UINy7f4QP 8B5e6w6CwP2ftgKb+VXQPft6ChlomT0J4oCN4icGVJoTId4ey3UuOTvx7pSWmcFAMRgv PiXp8j8cB/B8D+92L9BZChSMFsLOmNyfWmMJuhrhOhh2xBYs7rtHGPV4pYTqrtl3q/SF mF8rEN74tk54m6Y9Dzp3FYcu1bmgXMczCn5b4jLRzokjpEJs/kF6H2kNZLJFlyUwpZQE 8Byw== X-Gm-Message-State: ALyK8tKjumx5hxIxbvm0tB6dEMDTTnVnUwMXmOlqit7q/aSkWknFQiS66BrK5JWgT2+hdg== X-Received: by 10.66.157.193 with SMTP id wo1mr27941900pab.116.1465903023214; Tue, 14 Jun 2016 04:17:03 -0700 (PDT) Received: from E107787-LIN (gcc113.osuosl.org. [140.211.9.71]) by smtp.gmail.com with ESMTPSA id t65sm44683396pfb.37.2016.06.14.04.16.59 (version=TLS1_2 cipher=AES128-SHA bits=128/128); Tue, 14 Jun 2016 04:17:02 -0700 (PDT) From: Yao Qi To: Pedro Alves Cc: Yao Qi , gdb-patches@sourceware.org Subject: Re: [PATCH 04/12] Delete reinsert breakpoints from forked child References: <1464859846-15619-1-git-send-email-yao.qi@linaro.org> <1464859846-15619-5-git-send-email-yao.qi@linaro.org> <86twgxt4hg.fsf@gmail.com> Date: Tue, 14 Jun 2016 12:16:53 +0100 In-Reply-To: (Pedro Alves's message of "Mon, 13 Jun 2016 18:29:26 +0100") Message-ID: <86porkt3yy.fsf@gmail.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) MIME-Version: 1.0 X-IsSubscribed: yes Pedro Alves writes: >> I can't find another way to show the previous instruction. > > Now that the negative repeat count for 'x' patch [1] is in, > you can just do "x/-i $pc". Maybe "disassemble" could learn > to find boundaries similarly. > > But that x/-i trick only works if the code has line info available, > which you won't for _exit, unless you have debug info for glibc > installed. Maybe better is to just do "disassemble", with no args, > which disassembles the whole function. Yes, "disassemble" without args can do that. > > Or do it like step-over-syscall.exp does. > > [1] https://sourceware.org/ml/gdb-patches/2016-06/msg00021.html > I tried to avoid that approach in step-over-syscall.exp, because it may take so many instructions to single-step from fork () to the syscall instruction (due to spin lock in the execution path, I suspect), and test takes too long. I'll fix step-over-syscall.exp separately. >>> I'm thinking that it might be good for these tests to also have >>> a displaced-stepping on/off test axis. Or better still: >>> >>> out-of-line-step-over-bp / in-line-step-over-bp / plain-single-step >>> >> >> What is difference between the second one and third one? > > As I mention in the quoted sentence below, the last one > would single-step the instruction with no breakpoint > installed. The second one would have a breakpoint at PC, > which forces a step-over operation. With displaced step > off, that'd be an in-line step over. Thus the second one stops > all threads (and thus requires restarting them), while the > third one doesn't. > >> I think >> they've already covered by gdb.base/step-over-syscall.exp. > > In that case, shouldn't we be extending that test instead? OK, I extend step-over-syscall.exp by setting different combinations of follow-fork and detach-on-fork modes, and it still can trigger GDBserver internal errors. How about the patch below? It should be patch 5.5, after the bug fix patches (4 and 5) in this series. diff --git a/gdb/testsuite/gdb.base/step-over-syscall.exp b/gdb/testsuite/gdb.base/step-over-syscall.exp index 7e5a719..2809004 100644 --- a/gdb/testsuite/gdb.base/step-over-syscall.exp +++ b/gdb/testsuite/gdb.base/step-over-syscall.exp @@ -176,9 +176,11 @@ proc step_over_syscall { syscall } { # Set a breakpoint with a condition that evals false on syscall # instruction. In fact, it tests GDBserver steps over syscall -# instruction. +# instruction. SYSCALL is the syscall the program calls. +# FOLLOW_FORK is either "parent" or "child". DETACH_ON_FORK is +# "on" or "off". -proc break_cond_on_syscall { syscall } { +proc break_cond_on_syscall { syscall follow_fork detach_on_fork } { with_test_prefix "break cond on target : $syscall" { set testfile "step-over-$syscall" @@ -195,6 +197,8 @@ proc break_cond_on_syscall { syscall } { # Delete breakpoint syscall insns to avoid interference with other syscalls. delete_breakpoints + gdb_test "set follow-fork-mode $follow_fork" + gdb_test "set detach-on-fork $detach_on_fork" # Create a breakpoint with a condition that evals false. gdb_test "break \*$syscall_insn_addr if main == 0" \ @@ -212,9 +216,27 @@ proc break_cond_on_syscall { syscall } { gdb_test "break clone_fn if main == 0" } - gdb_test "break marker" "Breakpoint.*at.* file .*${testfile}.c, line.*" - gdb_test "continue" "Continuing\\..*Breakpoint \[0-9\]+, marker \\(\\) at.*" \ - "continue to marker ($syscall)" + if { $syscall == "clone" } { + # follow-fork and detach-on-fork only make sense to + # fork and vfork. + gdb_test "break marker" "Breakpoint.*at.* file .*${testfile}.c, line.*" + gdb_test "continue" "Continuing\\..*Breakpoint \[0-9\]+, marker \\(\\) at.*" \ + "continue to marker" + } else { + if { $follow_fork == "child" } { + gdb_test "continue" "exited normally.*" "continue to end of inf 2" + if { $detach_on_fork == "off" } { + gdb_test "inferior 1" + gdb_test "break marker" "Breakpoint.*at.*" + gdb_test "continue" "Continuing\\..*Breakpoint \[0-9\]+, marker \\(\\) at.*" \ + "continue to marker" + } + } else { + gdb_test "break marker" "Breakpoint.*at.* file .*${testfile}.c, line.*" + gdb_test "continue" "Continuing\\..*Breakpoint \[0-9\]+, marker \\(\\) at.*" \ + "continue to marker" + } + } } } @@ -243,7 +265,21 @@ gdb_test_multiple $test $test { } if { $cond_bp_target } { - break_cond_on_syscall "fork" - break_cond_on_syscall "vfork" - break_cond_on_syscall "clone" + + foreach_with_prefix detach-on-fork {"on" "off"} { + foreach_with_prefix follow-fork {"parent" "child"} { + foreach syscall { "fork" "vfork" "clone" } { + + if { $syscall != "vfork" + || ${follow-fork} != "parent" + || ${detach-on-fork} != "off" } { + # Both vforked child process and parent process are + # under GDB's control, but GDB follows the parent + # process only, which can't be run until vforked child + # finishes. Skip the test in this scenario. + break_cond_on_syscall $syscall ${follow-fork} ${detach-on-fork} + } + } + } + } }