Re: [PATCH 04/12] Delete reinsert breakpoints from forked child

[Yao Qi <qiyaoltc@gmail.com>]

Pedro Alves <palves@redhat.com> 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.

-- 
Yao (齐尧)

From a48fbab0961b5112bafd199f0ad298715a5e8eff Mon Sep 17 00:00:00 2001
From: Yao Qi <yao.qi@linaro.org>
Date: Tue, 14 Jun 2016 11:32:01 +0100
Subject: [PATCH] Extend step-over-syscall.exp with different detach-on-fork
 and follow-fork modes

This patch extends step-over-syscall.exp by setting different values to
detach-on-fork and follow-fork.

gdb/testsuite:

2016-06-14  Yao Qi  <yao.qi@linaro.org>

	* gdb.base/step-over-syscall.exp (break_cond_on_syscall): New
	parameters follow_fork and detach_on_fork.  Set follow-fork-mode
	and detach-on-fork.  Adjust tests.
	(top level): Invoke break_cond_on_syscall with combinations of
	syscall, follow-fork-mode and detach-on-fork.

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}
+		}
+	    }
+	}
+    }
 }