Fix for follow-fork: followed child doesn't stop
Commit Message
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. So when the child process is resumed, GDB doesn't insert
the breakpoint and the process runs to completion.
The solution is to clear the "inserted" flag when the single-step
breakpoint is associated with the child process.
Along with the fix above, the coverage of the follow-fork test
gdb.base/foll-fork.exp was expanded to:
1) cover all the combinations of values for
follow-fork-mode and detach-on-fork
2) make sure that both user breakpoints and
single-step breakpoints are propagated
correctly to the child
3) check that the inferior list has the
expected contents after following the fork.
This was tested by running the testsuite on a Linux x64 system.
Regards,
Don
gdb/
2014-06-04 Don Breazeal <donb@codesourcery.com>
* infrun.c (follow_fork): clear 'inserted' flag in single-
step breakpoint.
gdb/testsuite/
2014-06-04 Don Breazeal <donb@codesourcery.com>
* gdb.base/foll-fork.exp (default_fork_parent_follow):
Deleted procedure.
(explicit_fork_parent_follow): Deleted procedure.
(explicit_fork_child_follow): Deleted procedure.
(test_follow_fork): New procedure.
(do_fork_tests): Replace calls to deleted procedures with
calls to test_follow_fork and reset GDB for subsequent
procedure calls.
---
gdb/infrun.c | 2 +
gdb/testsuite/gdb.base/foll-fork.exp | 166 +++++++++++++++++++++-------------
2 files changed, 104 insertions(+), 64 deletions(-)
Comments
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.
Hi,
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. So when the child process is resumed, GDB doesn't insert
> the breakpoint and the process runs to completion.
>
> The solution is to clear the "inserted" flag when the single-step
> breakpoint is associated with the child process.
>
> Along with the fix above, the coverage of the follow-fork test
> gdb.base/foll-fork.exp was expanded to:
>
> 1) cover all the combinations of values for
> follow-fork-mode and detach-on-fork
>
> 2) make sure that both user breakpoints and
> single-step breakpoints are propagated
> correctly to the child
>
> 3) check that the inferior list has the
> expected contents after following the fork.
>
> This was tested by running the testsuite on a Linux x64 system.
>
> Regards,
> Don
>
Thanks. That is a nice addition.
> gdb/
>
> 2014-06-04 Don Breazeal <donb@codesourcery.com>
>
> * infrun.c (follow_fork): clear 'inserted' flag in single-
> step breakpoint.
>
> gdb/testsuite/
>
> 2014-06-04 Don Breazeal <donb@codesourcery.com>
>
> * gdb.base/foll-fork.exp (default_fork_parent_follow):
> Deleted procedure.
> (explicit_fork_parent_follow): Deleted procedure.
> (explicit_fork_child_follow): Deleted procedure.
> (test_follow_fork): New procedure.
> (do_fork_tests): Replace calls to deleted procedures with
> calls to test_follow_fork and reset GDB for subsequent
> procedure calls.
>
>
> ---
> gdb/infrun.c | 2 +
> gdb/testsuite/gdb.base/foll-fork.exp | 166 +++++++++++++++++++++-------------
> 2 files changed, 104 insertions(+), 64 deletions(-)
>
> diff --git a/gdb/infrun.c b/gdb/infrun.c
> index 47604c7..6c70cd0 100644
> --- a/gdb/infrun.c
> +++ b/gdb/infrun.c
> @@ -522,6 +522,8 @@ follow_fork (void)
> tp = inferior_thread ();
> tp->control.step_resume_breakpoint
> = step_resume_breakpoint;
> + if (tp->control.step_resume_breakpoint != NULL)
> + tp->control.step_resume_breakpoint->loc->inserted = 0;
> tp->control.step_range_start = step_range_start;
> tp->control.step_range_end = step_range_end;
> tp->control.step_frame_id = step_frame_id;
Maybe add a little more context as to why this conditional is doing what
it is doing? I imagine someone scratching their head to figure this out.
Your description above makes good sense.
> diff --git a/gdb/testsuite/gdb.base/foll-fork.exp b/gdb/testsuite/gdb.base/foll-fork.exp
> index e1201d7..c1ba041 100644
> --- a/gdb/testsuite/gdb.base/foll-fork.exp
> +++ b/gdb/testsuite/gdb.base/foll-fork.exp
> @@ -53,60 +53,100 @@ proc check_fork_catchpoints {} {
> }
> }
>
> -proc default_fork_parent_follow {} {
> +proc test_follow_fork { who detach cmd } {
> global gdb_prompt
> + global srcfile
> + global testfile
>
> - gdb_test "show follow-fork" \
> - "Debugger response to a program call of fork or vfork is \"parent\".*" \
> - "default show parent follow, no catchpoints"
> + set test_name "follow $who, detach $detach, command \"$cmd\""
>
> - gdb_test "next 2" \
> - "Detaching after fork from.*" \
> - "default parent follow, no catchpoints"
> + # Start a new debugger session each time so defaults are legitimate.
> + clean_restart $testfile
>
> - # The child has been detached; allow time for any output it might
> - # generate to arrive, so that output doesn't get confused with
> - # any expected debugger output from a subsequent testpoint.
> - #
> - exec sleep 1
> -}
> + if ![runto_main] {
> + untested "could not run to main"
> + return -1
> + }
>
> -proc explicit_fork_parent_follow {} {
> - global gdb_prompt
> + # The "Detaching..." and "Attaching..." messages may be hidden by
> + # default.
> + gdb_test_no_output "set verbose"
>
> - gdb_test_no_output "set follow-fork parent"
> + # Set follow-fork-mode if we aren't using the default.
> + if {$who == "default"} {
> + set who "parent"
> + } else {
> + gdb_test_no_output "set follow-fork $who"
> + }
>
> gdb_test "show follow-fork" \
> - "Debugger response to a program call of fork or vfork is \"parent\"." \
> - "explicit show parent follow, no catchpoints"
> + "Debugger response to a program call of fork or vfork is \"$who\"." \
> + "$test_name: show follow-fork"
> +
> + # Set detach-on-fork mode if we aren't using the default.
> + if {$detach == "default"} {
> + set detach "on"
> + } else {
> + gdb_test_no_output "set detach-on-fork $detach"
> + }
>
> - gdb_test "next 2" "Detaching after fork from.*" \
> - "explicit parent follow, no catchpoints"
> + gdb_test "show detach-on-fork" \
> + "Whether gdb will detach.* fork is $detach." \
> + "$test_name: show detach-on-fork"
> +
> + # Set the breakpoint after the fork if we aren't single-stepping
> + # past the fork.
> + if {$cmd == "continue"} {
> + set bp_after_fork [gdb_get_line_number "set breakpoint here"]
> + gdb_test "break ${srcfile}:$bp_after_fork" \
> + "Breakpoint.*, line $bp_after_fork.*" \
> + "$test_name: set breakpoint after fork"
> + }
>
> - # The child has been detached; allow time for any output it might
> - # generate to arrive, so that output doesn't get confused with
> - # any expected debugger output from a subsequent testpoint.
> - #
> - exec sleep 1
> -}
> + # Set up the output we expect to see after we run.
> + set expected_re ""
> + if {$who == "child"} {
> + set expected_re "Attaching after.* fork to.*set breakpoint here.*"
> + } elseif {$who == "parent" && $detach == "on"} {
> + set expected_re "Detaching after fork from .*set breakpoint here.*"
> + } else {
> + set expected_re ".*set breakpoint here.*"
> + }
>
> -proc explicit_fork_child_follow {} {
> - global gdb_prompt
> + # Test running past and following the fork, using the parameters
> + # set above.
> + gdb_test $cmd $expected_re "$test_name: $cmd past fork"
>
> - gdb_test_no_output "set follow-fork child"
> + # Check that we have the inferiors arranged correctly after
> + # following the fork.
> + if {$who == "parent" && $detach == "on"} {
>
> - gdb_test "show follow-fork" \
> - "Debugger response to a program call of fork or vfork is \"child\"." \
> - "explicit show child follow, no catchpoints"
> + # Follow parent / detach child: the only inferior is the parent.
> + gdb_test "info inferior" "\\* 1 .* process.*" \
> + "$test_name: info inferiors"
>
> - gdb_test "next 2" "Attaching after.* fork to.*" \
> - "explicit child follow, no catchpoints"
> + } elseif {$who == "parent" && $detach == "off"} {
>
> - # The child has been detached; allow time for any output it might
> - # generate to arrive, so that output doesn't get confused with
> - # any gdb_expected debugger output from a subsequent testpoint.
> - #
> - exec sleep 1
> + # Follow parent / keep child: two inferiors under debug, the
> + # parent is the current inferior.
> + gdb_test "info inferior" " 2 .*process.*\\* 1 .*process.*" \
> + "$test_name: info inferiors"
> +
> + } elseif {$who == "child" && $detach == "on"} {
> +
> + # Follow child / detach parent: the child is under debug and is
> + # the current inferior. The parent is listed but is not under
> + # debug.
> + gdb_test "info inferior" "\\* 2 .*process.* 1 .*<null>.*" \
> + "$test_name: info inferiors"
> +
> + } elseif {$who == "child" && $detach == "off"} {
> +
> + # Follow parent / keep child: two inferiors under debug, the
> + # child is the current inferior.
> + gdb_test "info inferior" "\\* 2 .*process.* 1 .*process.*" \
> + "$test_name: info inferiors"
> + }
> }
>
> proc catch_fork_child_follow {} {
> @@ -254,6 +294,7 @@ proc tcatch_fork_parent_follow {} {
>
> proc do_fork_tests {} {
> global gdb_prompt
> + global testfile
>
> # Verify that help is available for "set follow-fork-mode".
> #
> @@ -286,31 +327,28 @@ By default, the debugger will follow the parent process..*" \
> # fork-following is supported.
> if [runto_main] then { check_fork_catchpoints }
>
> - # Test the default behaviour, which is to follow the parent of a
> - # fork, and detach from the child. Do this without catchpoints.
> - #
> - if [runto_main] then { default_fork_parent_follow }
> -
> - # Test the ability to explicitly follow the parent of a fork, and
> - # detach from the child. Do this without catchpoints.
> - #
> - if [runto_main] then { explicit_fork_parent_follow }
> -
> - # Test the ability to follow the child of a fork, and detach from
> - # the parent. Do this without catchpoints.
> - #
> - if [runto_main] then { explicit_fork_child_follow }
> -
> - # Test the ability to follow both child and parent of a fork. Do
> - # this without catchpoints.
> - # ??rehrauer: NYI. Will add testpoints here when implemented.
> - #
> -
> - # Test the ability to have the debugger ask the user at fork-time
> - # whether to follow the parent, child or both. Do this without
> - # catchpoints.
> - # ??rehrauer: NYI. Will add testpoints here when implemented.
> - #
> + # Test all combinations of values for follow-fork-mode and
> + # detach-on-fork, using both a breakpoint and single-step
> + # to execute past the fork.
> + test_follow_fork "default" "default" "next 2"
> + test_follow_fork "default" "default" "continue"
> + # At this point we should be convinced that the defaults are either
> + # working or not working, so there is no need to test further using
> + # the defaults (e.g. "default" "on", "parent" "default", etc.).
> + test_follow_fork "parent" "on" "next 2"
> + test_follow_fork "parent" "on" "continue"
> + test_follow_fork "child" "on" "next 2"
> + test_follow_fork "child" "on" "continue"
> + test_follow_fork "parent" "off" "next 2"
> + test_follow_fork "parent" "off" "continue"
> + test_follow_fork "child" "off" "next 2"
> + test_follow_fork "child" "off" "continue"
Instead of hardcoding calls to tests, what about creating a list of
permutations (follow mode, detach on fork, execution command) and using
them inside a for loop?
That may be a bit cleaner, but i'm not totally against these calls.
> +
> + # Catchpoint tests.
> +
> + # Restart to eliminate any effects of the follow-fork tests.
> + clean_restart $testfile
> + gdb_test_no_output "set verbose"
>
> # Test the ability to catch a fork, specify that the child be
> # followed, and continue. Make the catchpoint permanent.
>
The rest of the test looks good to me.
Luis
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
On 06/05/2014 07:34 PM, Breazeal, Don wrote:
> 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.
It actually hasn't.
>
> 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.
No, when the parent's breakpoint is deleted, nothing is removed,
because the child's breakpoint, being a clone of the parent's is
still associated with the parent thread and pspace, so the breakpoints
module considers it a duplicate of the parent's sr breakpoint.
So, when we delete the parent breakpoint, given the child's is
around, we don't actually remove the breakpoint from the
target. We just happen to remove the new _child_'s breakpoint
from the parent a bit later when we detach the parent, again
because the child's is still associated with the parent:
(top-gdb) bt
#0 target_remove_breakpoint (gdbarch=0x1000ee0, bp_tgt=0x10db7d8) at ../../src/gdb/target.c:1938
#1 0x0000000000584aac in bkpt_remove_location (bl=0x10db740) at ../../src/gdb/breakpoint.c:13189
#2 0x0000000000574095 in remove_breakpoint_1 (bl=0x10db740, is=mark_uninserted) at ../../src/gdb/breakpoint.c:3823
#3 0x0000000000574436 in remove_breakpoint (bl=0x10db740, is=mark_uninserted) at ../../src/gdb/breakpoint.c:3940
#4 0x0000000000572d41 in remove_breakpoints_pid (pid=1408) at ../../src/gdb/breakpoint.c:3119
#5 0x000000000063d5f8 in target_detach (args=0x0, from_tty=0) at ../../src/gdb/target.c:2079
#6 0x00000000004b1c81 in linux_child_follow_fork (ops=0xdcfc30, follow_child=1, detach_fork=1) at ../../src/gdb/linux-nat.c:657
#7 0x00000000006372b6 in delegate_follow_fork (self=0xdcfc30, arg1=1, arg2=1) at ../../src/gdb/target-delegates.c:464
#8 0x000000000063daed in target_follow_fork (follow_child=1, detach_fork=1) at ../../src/gdb/target.c:2220
#9 0x00000000005eda7a in follow_fork () at ../../src/gdb/infrun.c:493
(top-gdb) up
#1 0x0000000000584aac in bkpt_remove_location (bl=0x10db740) at ../../src/gdb/breakpoint.c:13189
13189 return target_remove_breakpoint (bl->gdbarch, bp_tgt);
(top-gdb) p bl->owner->type
$8 = bp_step_resume
>
> 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...]
It hasn't here no. This is all quite brittle. :-/
I think we should instead make the clone be disabled to begin with,
so that it isn't marked as duplicate/inserted, and then re-enable it
in follow_inferior_reset_breakpoints, _after_ it's been re_set
to the child thread.
Also, exception_resume_breakpoint surely needs the same treatment.
@@ -522,6 +522,8 @@ follow_fork (void)
tp = inferior_thread ();
tp->control.step_resume_breakpoint
= step_resume_breakpoint;
+ if (tp->control.step_resume_breakpoint != NULL)
+ tp->control.step_resume_breakpoint->loc->inserted = 0;
tp->control.step_range_start = step_range_start;
tp->control.step_range_end = step_range_end;
tp->control.step_frame_id = step_frame_id;
@@ -53,60 +53,100 @@ proc check_fork_catchpoints {} {
}
}
-proc default_fork_parent_follow {} {
+proc test_follow_fork { who detach cmd } {
global gdb_prompt
+ global srcfile
+ global testfile
- gdb_test "show follow-fork" \
- "Debugger response to a program call of fork or vfork is \"parent\".*" \
- "default show parent follow, no catchpoints"
+ set test_name "follow $who, detach $detach, command \"$cmd\""
- gdb_test "next 2" \
- "Detaching after fork from.*" \
- "default parent follow, no catchpoints"
+ # Start a new debugger session each time so defaults are legitimate.
+ clean_restart $testfile
- # The child has been detached; allow time for any output it might
- # generate to arrive, so that output doesn't get confused with
- # any expected debugger output from a subsequent testpoint.
- #
- exec sleep 1
-}
+ if ![runto_main] {
+ untested "could not run to main"
+ return -1
+ }
-proc explicit_fork_parent_follow {} {
- global gdb_prompt
+ # The "Detaching..." and "Attaching..." messages may be hidden by
+ # default.
+ gdb_test_no_output "set verbose"
- gdb_test_no_output "set follow-fork parent"
+ # Set follow-fork-mode if we aren't using the default.
+ if {$who == "default"} {
+ set who "parent"
+ } else {
+ gdb_test_no_output "set follow-fork $who"
+ }
gdb_test "show follow-fork" \
- "Debugger response to a program call of fork or vfork is \"parent\"." \
- "explicit show parent follow, no catchpoints"
+ "Debugger response to a program call of fork or vfork is \"$who\"." \
+ "$test_name: show follow-fork"
+
+ # Set detach-on-fork mode if we aren't using the default.
+ if {$detach == "default"} {
+ set detach "on"
+ } else {
+ gdb_test_no_output "set detach-on-fork $detach"
+ }
- gdb_test "next 2" "Detaching after fork from.*" \
- "explicit parent follow, no catchpoints"
+ gdb_test "show detach-on-fork" \
+ "Whether gdb will detach.* fork is $detach." \
+ "$test_name: show detach-on-fork"
+
+ # Set the breakpoint after the fork if we aren't single-stepping
+ # past the fork.
+ if {$cmd == "continue"} {
+ set bp_after_fork [gdb_get_line_number "set breakpoint here"]
+ gdb_test "break ${srcfile}:$bp_after_fork" \
+ "Breakpoint.*, line $bp_after_fork.*" \
+ "$test_name: set breakpoint after fork"
+ }
- # The child has been detached; allow time for any output it might
- # generate to arrive, so that output doesn't get confused with
- # any expected debugger output from a subsequent testpoint.
- #
- exec sleep 1
-}
+ # Set up the output we expect to see after we run.
+ set expected_re ""
+ if {$who == "child"} {
+ set expected_re "Attaching after.* fork to.*set breakpoint here.*"
+ } elseif {$who == "parent" && $detach == "on"} {
+ set expected_re "Detaching after fork from .*set breakpoint here.*"
+ } else {
+ set expected_re ".*set breakpoint here.*"
+ }
-proc explicit_fork_child_follow {} {
- global gdb_prompt
+ # Test running past and following the fork, using the parameters
+ # set above.
+ gdb_test $cmd $expected_re "$test_name: $cmd past fork"
- gdb_test_no_output "set follow-fork child"
+ # Check that we have the inferiors arranged correctly after
+ # following the fork.
+ if {$who == "parent" && $detach == "on"} {
- gdb_test "show follow-fork" \
- "Debugger response to a program call of fork or vfork is \"child\"." \
- "explicit show child follow, no catchpoints"
+ # Follow parent / detach child: the only inferior is the parent.
+ gdb_test "info inferior" "\\* 1 .* process.*" \
+ "$test_name: info inferiors"
- gdb_test "next 2" "Attaching after.* fork to.*" \
- "explicit child follow, no catchpoints"
+ } elseif {$who == "parent" && $detach == "off"} {
- # The child has been detached; allow time for any output it might
- # generate to arrive, so that output doesn't get confused with
- # any gdb_expected debugger output from a subsequent testpoint.
- #
- exec sleep 1
+ # Follow parent / keep child: two inferiors under debug, the
+ # parent is the current inferior.
+ gdb_test "info inferior" " 2 .*process.*\\* 1 .*process.*" \
+ "$test_name: info inferiors"
+
+ } elseif {$who == "child" && $detach == "on"} {
+
+ # Follow child / detach parent: the child is under debug and is
+ # the current inferior. The parent is listed but is not under
+ # debug.
+ gdb_test "info inferior" "\\* 2 .*process.* 1 .*<null>.*" \
+ "$test_name: info inferiors"
+
+ } elseif {$who == "child" && $detach == "off"} {
+
+ # Follow parent / keep child: two inferiors under debug, the
+ # child is the current inferior.
+ gdb_test "info inferior" "\\* 2 .*process.* 1 .*process.*" \
+ "$test_name: info inferiors"
+ }
}
proc catch_fork_child_follow {} {
@@ -254,6 +294,7 @@ proc tcatch_fork_parent_follow {} {
proc do_fork_tests {} {
global gdb_prompt
+ global testfile
# Verify that help is available for "set follow-fork-mode".
#
@@ -286,31 +327,28 @@ By default, the debugger will follow the parent process..*" \
# fork-following is supported.
if [runto_main] then { check_fork_catchpoints }
- # Test the default behaviour, which is to follow the parent of a
- # fork, and detach from the child. Do this without catchpoints.
- #
- if [runto_main] then { default_fork_parent_follow }
-
- # Test the ability to explicitly follow the parent of a fork, and
- # detach from the child. Do this without catchpoints.
- #
- if [runto_main] then { explicit_fork_parent_follow }
-
- # Test the ability to follow the child of a fork, and detach from
- # the parent. Do this without catchpoints.
- #
- if [runto_main] then { explicit_fork_child_follow }
-
- # Test the ability to follow both child and parent of a fork. Do
- # this without catchpoints.
- # ??rehrauer: NYI. Will add testpoints here when implemented.
- #
-
- # Test the ability to have the debugger ask the user at fork-time
- # whether to follow the parent, child or both. Do this without
- # catchpoints.
- # ??rehrauer: NYI. Will add testpoints here when implemented.
- #
+ # Test all combinations of values for follow-fork-mode and
+ # detach-on-fork, using both a breakpoint and single-step
+ # to execute past the fork.
+ test_follow_fork "default" "default" "next 2"
+ test_follow_fork "default" "default" "continue"
+ # At this point we should be convinced that the defaults are either
+ # working or not working, so there is no need to test further using
+ # the defaults (e.g. "default" "on", "parent" "default", etc.).
+ test_follow_fork "parent" "on" "next 2"
+ test_follow_fork "parent" "on" "continue"
+ test_follow_fork "child" "on" "next 2"
+ test_follow_fork "child" "on" "continue"
+ test_follow_fork "parent" "off" "next 2"
+ test_follow_fork "parent" "off" "continue"
+ test_follow_fork "child" "off" "next 2"
+ test_follow_fork "child" "off" "continue"
+
+ # Catchpoint tests.
+
+ # Restart to eliminate any effects of the follow-fork tests.
+ clean_restart $testfile
+ gdb_test_no_output "set verbose"
# Test the ability to catch a fork, specify that the child be
# followed, and continue. Make the catchpoint permanent.