binutils-gdb/gdb/testsuite/gdb.base/foll-fork.exp

416 lines
13 KiB
Plaintext
Raw Normal View History

# Copyright 1997-2014 Free Software Foundation, Inc.
1999-06-29 07:04:32 +08:00
# This program is free software; you can redistribute it and/or modify
# it under the terms of the GNU General Public License as published by
# the Free Software Foundation; either version 3 of the License, or
1999-06-29 07:04:32 +08:00
# (at your option) any later version.
#
1999-06-29 07:04:32 +08:00
# This program is distributed in the hope that it will be useful,
# but WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
# GNU General Public License for more details.
#
1999-06-29 07:04:32 +08:00
# You should have received a copy of the GNU General Public License
# along with this program. If not, see <http://www.gnu.org/licenses/>.
1999-06-29 07:04:32 +08:00
if { [is_remote target] || ![isnative] } then {
1999-07-27 08:51:29 +08:00
continue
}
# Until "set follow-fork-mode" and "catch fork" are implemented on
# other targets...
#
if {![istarget "hppa*-hp-hpux*"] && ![istarget "*-linux*"]} then {
continue
}
1999-06-29 07:04:32 +08:00
standard_testfile
if {[prepare_for_testing $testfile.exp $testfile $srcfile debug]} {
untested $testfile.exp
return -1
1999-06-29 07:04:32 +08:00
}
proc check_fork_catchpoints {} {
global gdb_prompt
# Verify that the system supports "catch fork".
gdb_test "catch fork" "Catchpoint \[0-9\]* \\(fork\\)" "insert first fork catchpoint"
set has_fork_catchpoints 0
gdb_test_multiple "continue" "continue to first fork catchpoint" {
2010-01-11 Thiago Jung Bauermann <bauerman@br.ibm.com> Convert hardware watchpoints to use breakpoint_ops. gdb/ * breakpoint.h (breakpoint_ops) <insert>: Rename to... <insert_location>: ... this. Return int instead of void. Accept pointer to struct bp_location instead of pointer to struct breakpoint. Adapt all implementations. (breakpoint_ops) <remove>: Rename to... <remove_location>: ... this. Accept pointer to struct bp_location instead of pointer to struct breakpoint. Adapt all implementations. * breakpoint.c (insert_catchpoint): Delete function. (insert_bp_location): Call the watchpoint or catchpoint's breakpoint_ops.insert method. (remove_breakpoint_1): Call the watchpoint or catchpoint's breakpoint_ops.remove method. (insert_watchpoint, remove_watchpoint): New functions. (watchpoint_breakpoint_ops): New structure. (watch_command_1): Initialize the OPS field. * inf-child.c (inf_child_insert_fork_catchpoint) (inf_child_remove_fork_catchpoint, inf_child_insert_vfork_catchpoint) (inf_child_remove_vfork_catchpoint, inf_child_insert_exec_catchpoint) (inf_child_remove_exec_catchpoint, inf_child_set_syscall_catchpoint): Delete functions. (inf_child_target): Remove initialization of to_insert_fork_catchpoint, to_remove_fork_catchpoint, to_insert_vfork_catchpoint, to_remove_vfork_catchpoint, to_insert_exec_catchpoint, to_remove_exec_catchpoint and to_set_syscall_catchpoint. * target.c (update_current_target): Change default implementation of to_insert_fork_catchpoint, to_remove_fork_catchpoint, to_insert_vfork_catchpoint, to_remove_vfork_catchpoint, to_insert_exec_catchpoint, to_remove_exec_catchpoint and to_set_syscall_catchpoint to return_one. (debug_to_insert_fork_catchpoint, debug_to_insert_vfork_catchpoint) (debug_to_insert_exec_catchpoint): Report return value. * target.h (to_insert_fork_catchpoint, to_insert_vfork_catchpoint) (to_insert_exec_catchpoint): Change declaration to return int instead of void. gdb/testsuite/ * gdb.base/foll-exec.exp: Adapt to new error string when the catchpoint type is not supported. * gdb.base/foll-fork.exp: Likewise. * gdb.base/foll-vfork.exp: Likewise.
2011-01-12 03:16:23 +08:00
-re ".*Your system does not support this type\r\nof catchpoint.*$gdb_prompt $" {
unsupported "continue to first fork catchpoint"
}
-re ".*Catchpoint.*$gdb_prompt $" {
set has_fork_catchpoints 1
pass "continue to first fork catchpoint"
}
}
if {$has_fork_catchpoints == 0} {
unsupported "fork catchpoints"
return -code return
}
}
Symptom: Using the test program gdb.base/foll-fork.c, with follow-fork-mode set to "child" and detach-on-fork set to "off", stepping or running past the fork call results in the child process running to completion, when it should just finish the single step. In addition, the breakpoint is not removed from the parent process, so if it is resumed it receives a SIGTRAP. Cause: No matter what the setting for detach-on-fork, when stepping past a fork, the single-step breakpoint (step_resume_breakpoint) is not handled correctly in the parent. The SR breakpoint is cloned for the child process, but before the clone is associated with the child it is treated as a duplicate of the original, associated wth the parent. This results in the insertion state of the original SR breakpoint and the clone being "swapped" by breakpoint.c:update_global_location_list, so that the clone is marked as inserted. In the case where the parent is not detached, the two breakpoints remain in that state. The breakpoint is never inserted in the child, because although the cloned SR breakpoint is associated with the child, it is marked as inserted. When the child is resumed, it runs to completion. The breakpoint is never removed from the parent, so that if it is resumed after the child exits, it gets a SIGTRAP. Here is the sequence of events: 1) handle_inferior_event: FORK event is recognized. 2) handle_inferior_event: detach_breakpoints removes all breakpoints from the child. 3) follow_fork: the parent SR breakpoint is cloned. Part of this procedure is to call update_global_location_list, which swaps the insertion state of the original and cloned SR breakpoints as part of ensuring that duplicate breakpoints are only inserted once. At this point the original SR breakpoint is not marked as inserted, and the clone is. The breakpoint is actually inserted in the parent but not the child. 4) follow_fork: the original breakpoint is deleted by calling delete_step_resume_breakpoint. Since the original is not marked as inserted, the actual breakpoint remains in the parent process. update_global_location_list is called again as part of the deletion. The clone is still associated with the parent, but since it is marked as enabled and inserted, the breakpoint is left in the parent. 5) follow_fork: if detach-on-fork is 'on', the actual breakpoint will be removed from the parent in target_detach, based on the cloned breakpoint still associated with the parent. Then the clone is no longer marked as inserted. In follow_inferior_reset_breakpoints the clone is associated with the child, and can be inserted. If detach-on-fork is 'off', the actual breakpoint in the parent is never removed (although the breakpoint had been deleted from the list). Since the clone continues to be marked 'inserted', the SR breakpoint is never inserted in the child. Fix: Set the cloned breakpoint as disabled from the moment it is created. This is done by modifying clone_momentary_breakpoint to take an additional argument, LOC_ENABLED, which is used as the value of the bp_location->enabled member. The clone must be disabled at that point because clone_momentary_breakpoint calls update_global_location_list, which will swap treat the clone as a duplicate of the original breakpoint if it is enabled. All the calls to clone_momentary_breakpoint had to be modified to pass '1' or '0'. I looked at implementing an enum for the enabled member, but concluded that readability would suffer because there are so many places it is used as a boolean, e.g. "if (bl->enabled)". In follow_inferior_reset_breakpoints the clone is set to enabled once it has been associated with the child process. With this, the bp_location 'inserted' member is maintained correctly throughout the follow-fork procedure and the behavior is as expected. The same treatment is given to the exception_resume_breakpoint when following a fork. Testing: Ran 'make check' on Linux x64. 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. 4) check that unfollowed, undetached inferiors can be resumed. gdb/ 2014-06-18 Don Breazeal <donb@codesourcery.com> * breakpoint.c (set_longjmp_breakpoint): Call momentary_breakpoint_from_master with additional argument. (set_longjmp_breakpoint_for_call_dummy): Call momentary_breakpoint_from_master with additional argument. (set_std_terminate_breakpoint): Call momentary_breakpoint_from_master with additional argument. (momentary_breakpoint_from_master): Add argument to function definition and use it to initialize structure member flag. (clone_momentary_breakpoint): Call momentary_breakpoint_from_master with additional argument. * infrun.c (follow_inferior_reset_breakpoints): Clear structure member flags set in momentary_breakpoint_from_master. gdb/testsuite/ 2014-06-18 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.
2014-06-18 17:25:47 +08:00
# Test follow-fork to ensure that the correct process is followed, that
# the followed process stops where it is expected to stop, that processes
# are detached (or not) as expected, and that the inferior list has the
# expected contents after following the fork. WHO is the argument to
# the 'set follow-fork-mode' command, DETACH is the argument to the
# 'set detach-on-fork' command, and CMD is the GDB command used to
# execute the program past the fork. If the value of WHO or DETACH is
# 'default', the corresponding GDB command is skipped for that test.
# The value of CMD must be either 'next 2' or 'continue'.
proc test_follow_fork { who detach cmd } {
global gdb_prompt
Symptom: Using the test program gdb.base/foll-fork.c, with follow-fork-mode set to "child" and detach-on-fork set to "off", stepping or running past the fork call results in the child process running to completion, when it should just finish the single step. In addition, the breakpoint is not removed from the parent process, so if it is resumed it receives a SIGTRAP. Cause: No matter what the setting for detach-on-fork, when stepping past a fork, the single-step breakpoint (step_resume_breakpoint) is not handled correctly in the parent. The SR breakpoint is cloned for the child process, but before the clone is associated with the child it is treated as a duplicate of the original, associated wth the parent. This results in the insertion state of the original SR breakpoint and the clone being "swapped" by breakpoint.c:update_global_location_list, so that the clone is marked as inserted. In the case where the parent is not detached, the two breakpoints remain in that state. The breakpoint is never inserted in the child, because although the cloned SR breakpoint is associated with the child, it is marked as inserted. When the child is resumed, it runs to completion. The breakpoint is never removed from the parent, so that if it is resumed after the child exits, it gets a SIGTRAP. Here is the sequence of events: 1) handle_inferior_event: FORK event is recognized. 2) handle_inferior_event: detach_breakpoints removes all breakpoints from the child. 3) follow_fork: the parent SR breakpoint is cloned. Part of this procedure is to call update_global_location_list, which swaps the insertion state of the original and cloned SR breakpoints as part of ensuring that duplicate breakpoints are only inserted once. At this point the original SR breakpoint is not marked as inserted, and the clone is. The breakpoint is actually inserted in the parent but not the child. 4) follow_fork: the original breakpoint is deleted by calling delete_step_resume_breakpoint. Since the original is not marked as inserted, the actual breakpoint remains in the parent process. update_global_location_list is called again as part of the deletion. The clone is still associated with the parent, but since it is marked as enabled and inserted, the breakpoint is left in the parent. 5) follow_fork: if detach-on-fork is 'on', the actual breakpoint will be removed from the parent in target_detach, based on the cloned breakpoint still associated with the parent. Then the clone is no longer marked as inserted. In follow_inferior_reset_breakpoints the clone is associated with the child, and can be inserted. If detach-on-fork is 'off', the actual breakpoint in the parent is never removed (although the breakpoint had been deleted from the list). Since the clone continues to be marked 'inserted', the SR breakpoint is never inserted in the child. Fix: Set the cloned breakpoint as disabled from the moment it is created. This is done by modifying clone_momentary_breakpoint to take an additional argument, LOC_ENABLED, which is used as the value of the bp_location->enabled member. The clone must be disabled at that point because clone_momentary_breakpoint calls update_global_location_list, which will swap treat the clone as a duplicate of the original breakpoint if it is enabled. All the calls to clone_momentary_breakpoint had to be modified to pass '1' or '0'. I looked at implementing an enum for the enabled member, but concluded that readability would suffer because there are so many places it is used as a boolean, e.g. "if (bl->enabled)". In follow_inferior_reset_breakpoints the clone is set to enabled once it has been associated with the child process. With this, the bp_location 'inserted' member is maintained correctly throughout the follow-fork procedure and the behavior is as expected. The same treatment is given to the exception_resume_breakpoint when following a fork. Testing: Ran 'make check' on Linux x64. 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. 4) check that unfollowed, undetached inferiors can be resumed. gdb/ 2014-06-18 Don Breazeal <donb@codesourcery.com> * breakpoint.c (set_longjmp_breakpoint): Call momentary_breakpoint_from_master with additional argument. (set_longjmp_breakpoint_for_call_dummy): Call momentary_breakpoint_from_master with additional argument. (set_std_terminate_breakpoint): Call momentary_breakpoint_from_master with additional argument. (momentary_breakpoint_from_master): Add argument to function definition and use it to initialize structure member flag. (clone_momentary_breakpoint): Call momentary_breakpoint_from_master with additional argument. * infrun.c (follow_inferior_reset_breakpoints): Clear structure member flags set in momentary_breakpoint_from_master. gdb/testsuite/ 2014-06-18 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.
2014-06-18 17:25:47 +08:00
global srcfile
global testfile
Symptom: Using the test program gdb.base/foll-fork.c, with follow-fork-mode set to "child" and detach-on-fork set to "off", stepping or running past the fork call results in the child process running to completion, when it should just finish the single step. In addition, the breakpoint is not removed from the parent process, so if it is resumed it receives a SIGTRAP. Cause: No matter what the setting for detach-on-fork, when stepping past a fork, the single-step breakpoint (step_resume_breakpoint) is not handled correctly in the parent. The SR breakpoint is cloned for the child process, but before the clone is associated with the child it is treated as a duplicate of the original, associated wth the parent. This results in the insertion state of the original SR breakpoint and the clone being "swapped" by breakpoint.c:update_global_location_list, so that the clone is marked as inserted. In the case where the parent is not detached, the two breakpoints remain in that state. The breakpoint is never inserted in the child, because although the cloned SR breakpoint is associated with the child, it is marked as inserted. When the child is resumed, it runs to completion. The breakpoint is never removed from the parent, so that if it is resumed after the child exits, it gets a SIGTRAP. Here is the sequence of events: 1) handle_inferior_event: FORK event is recognized. 2) handle_inferior_event: detach_breakpoints removes all breakpoints from the child. 3) follow_fork: the parent SR breakpoint is cloned. Part of this procedure is to call update_global_location_list, which swaps the insertion state of the original and cloned SR breakpoints as part of ensuring that duplicate breakpoints are only inserted once. At this point the original SR breakpoint is not marked as inserted, and the clone is. The breakpoint is actually inserted in the parent but not the child. 4) follow_fork: the original breakpoint is deleted by calling delete_step_resume_breakpoint. Since the original is not marked as inserted, the actual breakpoint remains in the parent process. update_global_location_list is called again as part of the deletion. The clone is still associated with the parent, but since it is marked as enabled and inserted, the breakpoint is left in the parent. 5) follow_fork: if detach-on-fork is 'on', the actual breakpoint will be removed from the parent in target_detach, based on the cloned breakpoint still associated with the parent. Then the clone is no longer marked as inserted. In follow_inferior_reset_breakpoints the clone is associated with the child, and can be inserted. If detach-on-fork is 'off', the actual breakpoint in the parent is never removed (although the breakpoint had been deleted from the list). Since the clone continues to be marked 'inserted', the SR breakpoint is never inserted in the child. Fix: Set the cloned breakpoint as disabled from the moment it is created. This is done by modifying clone_momentary_breakpoint to take an additional argument, LOC_ENABLED, which is used as the value of the bp_location->enabled member. The clone must be disabled at that point because clone_momentary_breakpoint calls update_global_location_list, which will swap treat the clone as a duplicate of the original breakpoint if it is enabled. All the calls to clone_momentary_breakpoint had to be modified to pass '1' or '0'. I looked at implementing an enum for the enabled member, but concluded that readability would suffer because there are so many places it is used as a boolean, e.g. "if (bl->enabled)". In follow_inferior_reset_breakpoints the clone is set to enabled once it has been associated with the child process. With this, the bp_location 'inserted' member is maintained correctly throughout the follow-fork procedure and the behavior is as expected. The same treatment is given to the exception_resume_breakpoint when following a fork. Testing: Ran 'make check' on Linux x64. 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. 4) check that unfollowed, undetached inferiors can be resumed. gdb/ 2014-06-18 Don Breazeal <donb@codesourcery.com> * breakpoint.c (set_longjmp_breakpoint): Call momentary_breakpoint_from_master with additional argument. (set_longjmp_breakpoint_for_call_dummy): Call momentary_breakpoint_from_master with additional argument. (set_std_terminate_breakpoint): Call momentary_breakpoint_from_master with additional argument. (momentary_breakpoint_from_master): Add argument to function definition and use it to initialize structure member flag. (clone_momentary_breakpoint): Call momentary_breakpoint_from_master with additional argument. * infrun.c (follow_inferior_reset_breakpoints): Clear structure member flags set in momentary_breakpoint_from_master. gdb/testsuite/ 2014-06-18 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.
2014-06-18 17:25:47 +08:00
with_test_prefix "follow $who, detach $detach, command \"$cmd\"" {
Symptom: Using the test program gdb.base/foll-fork.c, with follow-fork-mode set to "child" and detach-on-fork set to "off", stepping or running past the fork call results in the child process running to completion, when it should just finish the single step. In addition, the breakpoint is not removed from the parent process, so if it is resumed it receives a SIGTRAP. Cause: No matter what the setting for detach-on-fork, when stepping past a fork, the single-step breakpoint (step_resume_breakpoint) is not handled correctly in the parent. The SR breakpoint is cloned for the child process, but before the clone is associated with the child it is treated as a duplicate of the original, associated wth the parent. This results in the insertion state of the original SR breakpoint and the clone being "swapped" by breakpoint.c:update_global_location_list, so that the clone is marked as inserted. In the case where the parent is not detached, the two breakpoints remain in that state. The breakpoint is never inserted in the child, because although the cloned SR breakpoint is associated with the child, it is marked as inserted. When the child is resumed, it runs to completion. The breakpoint is never removed from the parent, so that if it is resumed after the child exits, it gets a SIGTRAP. Here is the sequence of events: 1) handle_inferior_event: FORK event is recognized. 2) handle_inferior_event: detach_breakpoints removes all breakpoints from the child. 3) follow_fork: the parent SR breakpoint is cloned. Part of this procedure is to call update_global_location_list, which swaps the insertion state of the original and cloned SR breakpoints as part of ensuring that duplicate breakpoints are only inserted once. At this point the original SR breakpoint is not marked as inserted, and the clone is. The breakpoint is actually inserted in the parent but not the child. 4) follow_fork: the original breakpoint is deleted by calling delete_step_resume_breakpoint. Since the original is not marked as inserted, the actual breakpoint remains in the parent process. update_global_location_list is called again as part of the deletion. The clone is still associated with the parent, but since it is marked as enabled and inserted, the breakpoint is left in the parent. 5) follow_fork: if detach-on-fork is 'on', the actual breakpoint will be removed from the parent in target_detach, based on the cloned breakpoint still associated with the parent. Then the clone is no longer marked as inserted. In follow_inferior_reset_breakpoints the clone is associated with the child, and can be inserted. If detach-on-fork is 'off', the actual breakpoint in the parent is never removed (although the breakpoint had been deleted from the list). Since the clone continues to be marked 'inserted', the SR breakpoint is never inserted in the child. Fix: Set the cloned breakpoint as disabled from the moment it is created. This is done by modifying clone_momentary_breakpoint to take an additional argument, LOC_ENABLED, which is used as the value of the bp_location->enabled member. The clone must be disabled at that point because clone_momentary_breakpoint calls update_global_location_list, which will swap treat the clone as a duplicate of the original breakpoint if it is enabled. All the calls to clone_momentary_breakpoint had to be modified to pass '1' or '0'. I looked at implementing an enum for the enabled member, but concluded that readability would suffer because there are so many places it is used as a boolean, e.g. "if (bl->enabled)". In follow_inferior_reset_breakpoints the clone is set to enabled once it has been associated with the child process. With this, the bp_location 'inserted' member is maintained correctly throughout the follow-fork procedure and the behavior is as expected. The same treatment is given to the exception_resume_breakpoint when following a fork. Testing: Ran 'make check' on Linux x64. 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. 4) check that unfollowed, undetached inferiors can be resumed. gdb/ 2014-06-18 Don Breazeal <donb@codesourcery.com> * breakpoint.c (set_longjmp_breakpoint): Call momentary_breakpoint_from_master with additional argument. (set_longjmp_breakpoint_for_call_dummy): Call momentary_breakpoint_from_master with additional argument. (set_std_terminate_breakpoint): Call momentary_breakpoint_from_master with additional argument. (momentary_breakpoint_from_master): Add argument to function definition and use it to initialize structure member flag. (clone_momentary_breakpoint): Call momentary_breakpoint_from_master with additional argument. * infrun.c (follow_inferior_reset_breakpoints): Clear structure member flags set in momentary_breakpoint_from_master. gdb/testsuite/ 2014-06-18 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.
2014-06-18 17:25:47 +08:00
# Start a new debugger session each time so defaults are legitimate.
clean_restart $testfile
Symptom: Using the test program gdb.base/foll-fork.c, with follow-fork-mode set to "child" and detach-on-fork set to "off", stepping or running past the fork call results in the child process running to completion, when it should just finish the single step. In addition, the breakpoint is not removed from the parent process, so if it is resumed it receives a SIGTRAP. Cause: No matter what the setting for detach-on-fork, when stepping past a fork, the single-step breakpoint (step_resume_breakpoint) is not handled correctly in the parent. The SR breakpoint is cloned for the child process, but before the clone is associated with the child it is treated as a duplicate of the original, associated wth the parent. This results in the insertion state of the original SR breakpoint and the clone being "swapped" by breakpoint.c:update_global_location_list, so that the clone is marked as inserted. In the case where the parent is not detached, the two breakpoints remain in that state. The breakpoint is never inserted in the child, because although the cloned SR breakpoint is associated with the child, it is marked as inserted. When the child is resumed, it runs to completion. The breakpoint is never removed from the parent, so that if it is resumed after the child exits, it gets a SIGTRAP. Here is the sequence of events: 1) handle_inferior_event: FORK event is recognized. 2) handle_inferior_event: detach_breakpoints removes all breakpoints from the child. 3) follow_fork: the parent SR breakpoint is cloned. Part of this procedure is to call update_global_location_list, which swaps the insertion state of the original and cloned SR breakpoints as part of ensuring that duplicate breakpoints are only inserted once. At this point the original SR breakpoint is not marked as inserted, and the clone is. The breakpoint is actually inserted in the parent but not the child. 4) follow_fork: the original breakpoint is deleted by calling delete_step_resume_breakpoint. Since the original is not marked as inserted, the actual breakpoint remains in the parent process. update_global_location_list is called again as part of the deletion. The clone is still associated with the parent, but since it is marked as enabled and inserted, the breakpoint is left in the parent. 5) follow_fork: if detach-on-fork is 'on', the actual breakpoint will be removed from the parent in target_detach, based on the cloned breakpoint still associated with the parent. Then the clone is no longer marked as inserted. In follow_inferior_reset_breakpoints the clone is associated with the child, and can be inserted. If detach-on-fork is 'off', the actual breakpoint in the parent is never removed (although the breakpoint had been deleted from the list). Since the clone continues to be marked 'inserted', the SR breakpoint is never inserted in the child. Fix: Set the cloned breakpoint as disabled from the moment it is created. This is done by modifying clone_momentary_breakpoint to take an additional argument, LOC_ENABLED, which is used as the value of the bp_location->enabled member. The clone must be disabled at that point because clone_momentary_breakpoint calls update_global_location_list, which will swap treat the clone as a duplicate of the original breakpoint if it is enabled. All the calls to clone_momentary_breakpoint had to be modified to pass '1' or '0'. I looked at implementing an enum for the enabled member, but concluded that readability would suffer because there are so many places it is used as a boolean, e.g. "if (bl->enabled)". In follow_inferior_reset_breakpoints the clone is set to enabled once it has been associated with the child process. With this, the bp_location 'inserted' member is maintained correctly throughout the follow-fork procedure and the behavior is as expected. The same treatment is given to the exception_resume_breakpoint when following a fork. Testing: Ran 'make check' on Linux x64. 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. 4) check that unfollowed, undetached inferiors can be resumed. gdb/ 2014-06-18 Don Breazeal <donb@codesourcery.com> * breakpoint.c (set_longjmp_breakpoint): Call momentary_breakpoint_from_master with additional argument. (set_longjmp_breakpoint_for_call_dummy): Call momentary_breakpoint_from_master with additional argument. (set_std_terminate_breakpoint): Call momentary_breakpoint_from_master with additional argument. (momentary_breakpoint_from_master): Add argument to function definition and use it to initialize structure member flag. (clone_momentary_breakpoint): Call momentary_breakpoint_from_master with additional argument. * infrun.c (follow_inferior_reset_breakpoints): Clear structure member flags set in momentary_breakpoint_from_master. gdb/testsuite/ 2014-06-18 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.
2014-06-18 17:25:47 +08:00
if ![runto_main] {
untested "could not run to main"
return -1
}
1999-06-29 07:04:32 +08:00
Symptom: Using the test program gdb.base/foll-fork.c, with follow-fork-mode set to "child" and detach-on-fork set to "off", stepping or running past the fork call results in the child process running to completion, when it should just finish the single step. In addition, the breakpoint is not removed from the parent process, so if it is resumed it receives a SIGTRAP. Cause: No matter what the setting for detach-on-fork, when stepping past a fork, the single-step breakpoint (step_resume_breakpoint) is not handled correctly in the parent. The SR breakpoint is cloned for the child process, but before the clone is associated with the child it is treated as a duplicate of the original, associated wth the parent. This results in the insertion state of the original SR breakpoint and the clone being "swapped" by breakpoint.c:update_global_location_list, so that the clone is marked as inserted. In the case where the parent is not detached, the two breakpoints remain in that state. The breakpoint is never inserted in the child, because although the cloned SR breakpoint is associated with the child, it is marked as inserted. When the child is resumed, it runs to completion. The breakpoint is never removed from the parent, so that if it is resumed after the child exits, it gets a SIGTRAP. Here is the sequence of events: 1) handle_inferior_event: FORK event is recognized. 2) handle_inferior_event: detach_breakpoints removes all breakpoints from the child. 3) follow_fork: the parent SR breakpoint is cloned. Part of this procedure is to call update_global_location_list, which swaps the insertion state of the original and cloned SR breakpoints as part of ensuring that duplicate breakpoints are only inserted once. At this point the original SR breakpoint is not marked as inserted, and the clone is. The breakpoint is actually inserted in the parent but not the child. 4) follow_fork: the original breakpoint is deleted by calling delete_step_resume_breakpoint. Since the original is not marked as inserted, the actual breakpoint remains in the parent process. update_global_location_list is called again as part of the deletion. The clone is still associated with the parent, but since it is marked as enabled and inserted, the breakpoint is left in the parent. 5) follow_fork: if detach-on-fork is 'on', the actual breakpoint will be removed from the parent in target_detach, based on the cloned breakpoint still associated with the parent. Then the clone is no longer marked as inserted. In follow_inferior_reset_breakpoints the clone is associated with the child, and can be inserted. If detach-on-fork is 'off', the actual breakpoint in the parent is never removed (although the breakpoint had been deleted from the list). Since the clone continues to be marked 'inserted', the SR breakpoint is never inserted in the child. Fix: Set the cloned breakpoint as disabled from the moment it is created. This is done by modifying clone_momentary_breakpoint to take an additional argument, LOC_ENABLED, which is used as the value of the bp_location->enabled member. The clone must be disabled at that point because clone_momentary_breakpoint calls update_global_location_list, which will swap treat the clone as a duplicate of the original breakpoint if it is enabled. All the calls to clone_momentary_breakpoint had to be modified to pass '1' or '0'. I looked at implementing an enum for the enabled member, but concluded that readability would suffer because there are so many places it is used as a boolean, e.g. "if (bl->enabled)". In follow_inferior_reset_breakpoints the clone is set to enabled once it has been associated with the child process. With this, the bp_location 'inserted' member is maintained correctly throughout the follow-fork procedure and the behavior is as expected. The same treatment is given to the exception_resume_breakpoint when following a fork. Testing: Ran 'make check' on Linux x64. 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. 4) check that unfollowed, undetached inferiors can be resumed. gdb/ 2014-06-18 Don Breazeal <donb@codesourcery.com> * breakpoint.c (set_longjmp_breakpoint): Call momentary_breakpoint_from_master with additional argument. (set_longjmp_breakpoint_for_call_dummy): Call momentary_breakpoint_from_master with additional argument. (set_std_terminate_breakpoint): Call momentary_breakpoint_from_master with additional argument. (momentary_breakpoint_from_master): Add argument to function definition and use it to initialize structure member flag. (clone_momentary_breakpoint): Call momentary_breakpoint_from_master with additional argument. * infrun.c (follow_inferior_reset_breakpoints): Clear structure member flags set in momentary_breakpoint_from_master. gdb/testsuite/ 2014-06-18 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.
2014-06-18 17:25:47 +08:00
# The "Detaching..." and "Attaching..." messages may be hidden by
# default.
gdb_test_no_output "set verbose"
Symptom: Using the test program gdb.base/foll-fork.c, with follow-fork-mode set to "child" and detach-on-fork set to "off", stepping or running past the fork call results in the child process running to completion, when it should just finish the single step. In addition, the breakpoint is not removed from the parent process, so if it is resumed it receives a SIGTRAP. Cause: No matter what the setting for detach-on-fork, when stepping past a fork, the single-step breakpoint (step_resume_breakpoint) is not handled correctly in the parent. The SR breakpoint is cloned for the child process, but before the clone is associated with the child it is treated as a duplicate of the original, associated wth the parent. This results in the insertion state of the original SR breakpoint and the clone being "swapped" by breakpoint.c:update_global_location_list, so that the clone is marked as inserted. In the case where the parent is not detached, the two breakpoints remain in that state. The breakpoint is never inserted in the child, because although the cloned SR breakpoint is associated with the child, it is marked as inserted. When the child is resumed, it runs to completion. The breakpoint is never removed from the parent, so that if it is resumed after the child exits, it gets a SIGTRAP. Here is the sequence of events: 1) handle_inferior_event: FORK event is recognized. 2) handle_inferior_event: detach_breakpoints removes all breakpoints from the child. 3) follow_fork: the parent SR breakpoint is cloned. Part of this procedure is to call update_global_location_list, which swaps the insertion state of the original and cloned SR breakpoints as part of ensuring that duplicate breakpoints are only inserted once. At this point the original SR breakpoint is not marked as inserted, and the clone is. The breakpoint is actually inserted in the parent but not the child. 4) follow_fork: the original breakpoint is deleted by calling delete_step_resume_breakpoint. Since the original is not marked as inserted, the actual breakpoint remains in the parent process. update_global_location_list is called again as part of the deletion. The clone is still associated with the parent, but since it is marked as enabled and inserted, the breakpoint is left in the parent. 5) follow_fork: if detach-on-fork is 'on', the actual breakpoint will be removed from the parent in target_detach, based on the cloned breakpoint still associated with the parent. Then the clone is no longer marked as inserted. In follow_inferior_reset_breakpoints the clone is associated with the child, and can be inserted. If detach-on-fork is 'off', the actual breakpoint in the parent is never removed (although the breakpoint had been deleted from the list). Since the clone continues to be marked 'inserted', the SR breakpoint is never inserted in the child. Fix: Set the cloned breakpoint as disabled from the moment it is created. This is done by modifying clone_momentary_breakpoint to take an additional argument, LOC_ENABLED, which is used as the value of the bp_location->enabled member. The clone must be disabled at that point because clone_momentary_breakpoint calls update_global_location_list, which will swap treat the clone as a duplicate of the original breakpoint if it is enabled. All the calls to clone_momentary_breakpoint had to be modified to pass '1' or '0'. I looked at implementing an enum for the enabled member, but concluded that readability would suffer because there are so many places it is used as a boolean, e.g. "if (bl->enabled)". In follow_inferior_reset_breakpoints the clone is set to enabled once it has been associated with the child process. With this, the bp_location 'inserted' member is maintained correctly throughout the follow-fork procedure and the behavior is as expected. The same treatment is given to the exception_resume_breakpoint when following a fork. Testing: Ran 'make check' on Linux x64. 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. 4) check that unfollowed, undetached inferiors can be resumed. gdb/ 2014-06-18 Don Breazeal <donb@codesourcery.com> * breakpoint.c (set_longjmp_breakpoint): Call momentary_breakpoint_from_master with additional argument. (set_longjmp_breakpoint_for_call_dummy): Call momentary_breakpoint_from_master with additional argument. (set_std_terminate_breakpoint): Call momentary_breakpoint_from_master with additional argument. (momentary_breakpoint_from_master): Add argument to function definition and use it to initialize structure member flag. (clone_momentary_breakpoint): Call momentary_breakpoint_from_master with additional argument. * infrun.c (follow_inferior_reset_breakpoints): Clear structure member flags set in momentary_breakpoint_from_master. gdb/testsuite/ 2014-06-18 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.
2014-06-18 17:25:47 +08:00
# 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"
}
Symptom: Using the test program gdb.base/foll-fork.c, with follow-fork-mode set to "child" and detach-on-fork set to "off", stepping or running past the fork call results in the child process running to completion, when it should just finish the single step. In addition, the breakpoint is not removed from the parent process, so if it is resumed it receives a SIGTRAP. Cause: No matter what the setting for detach-on-fork, when stepping past a fork, the single-step breakpoint (step_resume_breakpoint) is not handled correctly in the parent. The SR breakpoint is cloned for the child process, but before the clone is associated with the child it is treated as a duplicate of the original, associated wth the parent. This results in the insertion state of the original SR breakpoint and the clone being "swapped" by breakpoint.c:update_global_location_list, so that the clone is marked as inserted. In the case where the parent is not detached, the two breakpoints remain in that state. The breakpoint is never inserted in the child, because although the cloned SR breakpoint is associated with the child, it is marked as inserted. When the child is resumed, it runs to completion. The breakpoint is never removed from the parent, so that if it is resumed after the child exits, it gets a SIGTRAP. Here is the sequence of events: 1) handle_inferior_event: FORK event is recognized. 2) handle_inferior_event: detach_breakpoints removes all breakpoints from the child. 3) follow_fork: the parent SR breakpoint is cloned. Part of this procedure is to call update_global_location_list, which swaps the insertion state of the original and cloned SR breakpoints as part of ensuring that duplicate breakpoints are only inserted once. At this point the original SR breakpoint is not marked as inserted, and the clone is. The breakpoint is actually inserted in the parent but not the child. 4) follow_fork: the original breakpoint is deleted by calling delete_step_resume_breakpoint. Since the original is not marked as inserted, the actual breakpoint remains in the parent process. update_global_location_list is called again as part of the deletion. The clone is still associated with the parent, but since it is marked as enabled and inserted, the breakpoint is left in the parent. 5) follow_fork: if detach-on-fork is 'on', the actual breakpoint will be removed from the parent in target_detach, based on the cloned breakpoint still associated with the parent. Then the clone is no longer marked as inserted. In follow_inferior_reset_breakpoints the clone is associated with the child, and can be inserted. If detach-on-fork is 'off', the actual breakpoint in the parent is never removed (although the breakpoint had been deleted from the list). Since the clone continues to be marked 'inserted', the SR breakpoint is never inserted in the child. Fix: Set the cloned breakpoint as disabled from the moment it is created. This is done by modifying clone_momentary_breakpoint to take an additional argument, LOC_ENABLED, which is used as the value of the bp_location->enabled member. The clone must be disabled at that point because clone_momentary_breakpoint calls update_global_location_list, which will swap treat the clone as a duplicate of the original breakpoint if it is enabled. All the calls to clone_momentary_breakpoint had to be modified to pass '1' or '0'. I looked at implementing an enum for the enabled member, but concluded that readability would suffer because there are so many places it is used as a boolean, e.g. "if (bl->enabled)". In follow_inferior_reset_breakpoints the clone is set to enabled once it has been associated with the child process. With this, the bp_location 'inserted' member is maintained correctly throughout the follow-fork procedure and the behavior is as expected. The same treatment is given to the exception_resume_breakpoint when following a fork. Testing: Ran 'make check' on Linux x64. 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. 4) check that unfollowed, undetached inferiors can be resumed. gdb/ 2014-06-18 Don Breazeal <donb@codesourcery.com> * breakpoint.c (set_longjmp_breakpoint): Call momentary_breakpoint_from_master with additional argument. (set_longjmp_breakpoint_for_call_dummy): Call momentary_breakpoint_from_master with additional argument. (set_std_terminate_breakpoint): Call momentary_breakpoint_from_master with additional argument. (momentary_breakpoint_from_master): Add argument to function definition and use it to initialize structure member flag. (clone_momentary_breakpoint): Call momentary_breakpoint_from_master with additional argument. * infrun.c (follow_inferior_reset_breakpoints): Clear structure member flags set in momentary_breakpoint_from_master. gdb/testsuite/ 2014-06-18 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.
2014-06-18 17:25:47 +08:00
gdb_test "show follow-fork" \
"Debugger response to a program call of fork or vfork is \"$who\"." \
"show follow-fork"
Symptom: Using the test program gdb.base/foll-fork.c, with follow-fork-mode set to "child" and detach-on-fork set to "off", stepping or running past the fork call results in the child process running to completion, when it should just finish the single step. In addition, the breakpoint is not removed from the parent process, so if it is resumed it receives a SIGTRAP. Cause: No matter what the setting for detach-on-fork, when stepping past a fork, the single-step breakpoint (step_resume_breakpoint) is not handled correctly in the parent. The SR breakpoint is cloned for the child process, but before the clone is associated with the child it is treated as a duplicate of the original, associated wth the parent. This results in the insertion state of the original SR breakpoint and the clone being "swapped" by breakpoint.c:update_global_location_list, so that the clone is marked as inserted. In the case where the parent is not detached, the two breakpoints remain in that state. The breakpoint is never inserted in the child, because although the cloned SR breakpoint is associated with the child, it is marked as inserted. When the child is resumed, it runs to completion. The breakpoint is never removed from the parent, so that if it is resumed after the child exits, it gets a SIGTRAP. Here is the sequence of events: 1) handle_inferior_event: FORK event is recognized. 2) handle_inferior_event: detach_breakpoints removes all breakpoints from the child. 3) follow_fork: the parent SR breakpoint is cloned. Part of this procedure is to call update_global_location_list, which swaps the insertion state of the original and cloned SR breakpoints as part of ensuring that duplicate breakpoints are only inserted once. At this point the original SR breakpoint is not marked as inserted, and the clone is. The breakpoint is actually inserted in the parent but not the child. 4) follow_fork: the original breakpoint is deleted by calling delete_step_resume_breakpoint. Since the original is not marked as inserted, the actual breakpoint remains in the parent process. update_global_location_list is called again as part of the deletion. The clone is still associated with the parent, but since it is marked as enabled and inserted, the breakpoint is left in the parent. 5) follow_fork: if detach-on-fork is 'on', the actual breakpoint will be removed from the parent in target_detach, based on the cloned breakpoint still associated with the parent. Then the clone is no longer marked as inserted. In follow_inferior_reset_breakpoints the clone is associated with the child, and can be inserted. If detach-on-fork is 'off', the actual breakpoint in the parent is never removed (although the breakpoint had been deleted from the list). Since the clone continues to be marked 'inserted', the SR breakpoint is never inserted in the child. Fix: Set the cloned breakpoint as disabled from the moment it is created. This is done by modifying clone_momentary_breakpoint to take an additional argument, LOC_ENABLED, which is used as the value of the bp_location->enabled member. The clone must be disabled at that point because clone_momentary_breakpoint calls update_global_location_list, which will swap treat the clone as a duplicate of the original breakpoint if it is enabled. All the calls to clone_momentary_breakpoint had to be modified to pass '1' or '0'. I looked at implementing an enum for the enabled member, but concluded that readability would suffer because there are so many places it is used as a boolean, e.g. "if (bl->enabled)". In follow_inferior_reset_breakpoints the clone is set to enabled once it has been associated with the child process. With this, the bp_location 'inserted' member is maintained correctly throughout the follow-fork procedure and the behavior is as expected. The same treatment is given to the exception_resume_breakpoint when following a fork. Testing: Ran 'make check' on Linux x64. 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. 4) check that unfollowed, undetached inferiors can be resumed. gdb/ 2014-06-18 Don Breazeal <donb@codesourcery.com> * breakpoint.c (set_longjmp_breakpoint): Call momentary_breakpoint_from_master with additional argument. (set_longjmp_breakpoint_for_call_dummy): Call momentary_breakpoint_from_master with additional argument. (set_std_terminate_breakpoint): Call momentary_breakpoint_from_master with additional argument. (momentary_breakpoint_from_master): Add argument to function definition and use it to initialize structure member flag. (clone_momentary_breakpoint): Call momentary_breakpoint_from_master with additional argument. * infrun.c (follow_inferior_reset_breakpoints): Clear structure member flags set in momentary_breakpoint_from_master. gdb/testsuite/ 2014-06-18 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.
2014-06-18 17:25:47 +08:00
# 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"
}
Symptom: Using the test program gdb.base/foll-fork.c, with follow-fork-mode set to "child" and detach-on-fork set to "off", stepping or running past the fork call results in the child process running to completion, when it should just finish the single step. In addition, the breakpoint is not removed from the parent process, so if it is resumed it receives a SIGTRAP. Cause: No matter what the setting for detach-on-fork, when stepping past a fork, the single-step breakpoint (step_resume_breakpoint) is not handled correctly in the parent. The SR breakpoint is cloned for the child process, but before the clone is associated with the child it is treated as a duplicate of the original, associated wth the parent. This results in the insertion state of the original SR breakpoint and the clone being "swapped" by breakpoint.c:update_global_location_list, so that the clone is marked as inserted. In the case where the parent is not detached, the two breakpoints remain in that state. The breakpoint is never inserted in the child, because although the cloned SR breakpoint is associated with the child, it is marked as inserted. When the child is resumed, it runs to completion. The breakpoint is never removed from the parent, so that if it is resumed after the child exits, it gets a SIGTRAP. Here is the sequence of events: 1) handle_inferior_event: FORK event is recognized. 2) handle_inferior_event: detach_breakpoints removes all breakpoints from the child. 3) follow_fork: the parent SR breakpoint is cloned. Part of this procedure is to call update_global_location_list, which swaps the insertion state of the original and cloned SR breakpoints as part of ensuring that duplicate breakpoints are only inserted once. At this point the original SR breakpoint is not marked as inserted, and the clone is. The breakpoint is actually inserted in the parent but not the child. 4) follow_fork: the original breakpoint is deleted by calling delete_step_resume_breakpoint. Since the original is not marked as inserted, the actual breakpoint remains in the parent process. update_global_location_list is called again as part of the deletion. The clone is still associated with the parent, but since it is marked as enabled and inserted, the breakpoint is left in the parent. 5) follow_fork: if detach-on-fork is 'on', the actual breakpoint will be removed from the parent in target_detach, based on the cloned breakpoint still associated with the parent. Then the clone is no longer marked as inserted. In follow_inferior_reset_breakpoints the clone is associated with the child, and can be inserted. If detach-on-fork is 'off', the actual breakpoint in the parent is never removed (although the breakpoint had been deleted from the list). Since the clone continues to be marked 'inserted', the SR breakpoint is never inserted in the child. Fix: Set the cloned breakpoint as disabled from the moment it is created. This is done by modifying clone_momentary_breakpoint to take an additional argument, LOC_ENABLED, which is used as the value of the bp_location->enabled member. The clone must be disabled at that point because clone_momentary_breakpoint calls update_global_location_list, which will swap treat the clone as a duplicate of the original breakpoint if it is enabled. All the calls to clone_momentary_breakpoint had to be modified to pass '1' or '0'. I looked at implementing an enum for the enabled member, but concluded that readability would suffer because there are so many places it is used as a boolean, e.g. "if (bl->enabled)". In follow_inferior_reset_breakpoints the clone is set to enabled once it has been associated with the child process. With this, the bp_location 'inserted' member is maintained correctly throughout the follow-fork procedure and the behavior is as expected. The same treatment is given to the exception_resume_breakpoint when following a fork. Testing: Ran 'make check' on Linux x64. 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. 4) check that unfollowed, undetached inferiors can be resumed. gdb/ 2014-06-18 Don Breazeal <donb@codesourcery.com> * breakpoint.c (set_longjmp_breakpoint): Call momentary_breakpoint_from_master with additional argument. (set_longjmp_breakpoint_for_call_dummy): Call momentary_breakpoint_from_master with additional argument. (set_std_terminate_breakpoint): Call momentary_breakpoint_from_master with additional argument. (momentary_breakpoint_from_master): Add argument to function definition and use it to initialize structure member flag. (clone_momentary_breakpoint): Call momentary_breakpoint_from_master with additional argument. * infrun.c (follow_inferior_reset_breakpoints): Clear structure member flags set in momentary_breakpoint_from_master. gdb/testsuite/ 2014-06-18 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.
2014-06-18 17:25:47 +08:00
gdb_test "show detach-on-fork" \
"Whether gdb will detach.* fork is $detach." \
"show detach-on-fork"
# Set a 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.*" \
"set breakpoint after fork"
}
1999-06-29 07:04:32 +08:00
Symptom: Using the test program gdb.base/foll-fork.c, with follow-fork-mode set to "child" and detach-on-fork set to "off", stepping or running past the fork call results in the child process running to completion, when it should just finish the single step. In addition, the breakpoint is not removed from the parent process, so if it is resumed it receives a SIGTRAP. Cause: No matter what the setting for detach-on-fork, when stepping past a fork, the single-step breakpoint (step_resume_breakpoint) is not handled correctly in the parent. The SR breakpoint is cloned for the child process, but before the clone is associated with the child it is treated as a duplicate of the original, associated wth the parent. This results in the insertion state of the original SR breakpoint and the clone being "swapped" by breakpoint.c:update_global_location_list, so that the clone is marked as inserted. In the case where the parent is not detached, the two breakpoints remain in that state. The breakpoint is never inserted in the child, because although the cloned SR breakpoint is associated with the child, it is marked as inserted. When the child is resumed, it runs to completion. The breakpoint is never removed from the parent, so that if it is resumed after the child exits, it gets a SIGTRAP. Here is the sequence of events: 1) handle_inferior_event: FORK event is recognized. 2) handle_inferior_event: detach_breakpoints removes all breakpoints from the child. 3) follow_fork: the parent SR breakpoint is cloned. Part of this procedure is to call update_global_location_list, which swaps the insertion state of the original and cloned SR breakpoints as part of ensuring that duplicate breakpoints are only inserted once. At this point the original SR breakpoint is not marked as inserted, and the clone is. The breakpoint is actually inserted in the parent but not the child. 4) follow_fork: the original breakpoint is deleted by calling delete_step_resume_breakpoint. Since the original is not marked as inserted, the actual breakpoint remains in the parent process. update_global_location_list is called again as part of the deletion. The clone is still associated with the parent, but since it is marked as enabled and inserted, the breakpoint is left in the parent. 5) follow_fork: if detach-on-fork is 'on', the actual breakpoint will be removed from the parent in target_detach, based on the cloned breakpoint still associated with the parent. Then the clone is no longer marked as inserted. In follow_inferior_reset_breakpoints the clone is associated with the child, and can be inserted. If detach-on-fork is 'off', the actual breakpoint in the parent is never removed (although the breakpoint had been deleted from the list). Since the clone continues to be marked 'inserted', the SR breakpoint is never inserted in the child. Fix: Set the cloned breakpoint as disabled from the moment it is created. This is done by modifying clone_momentary_breakpoint to take an additional argument, LOC_ENABLED, which is used as the value of the bp_location->enabled member. The clone must be disabled at that point because clone_momentary_breakpoint calls update_global_location_list, which will swap treat the clone as a duplicate of the original breakpoint if it is enabled. All the calls to clone_momentary_breakpoint had to be modified to pass '1' or '0'. I looked at implementing an enum for the enabled member, but concluded that readability would suffer because there are so many places it is used as a boolean, e.g. "if (bl->enabled)". In follow_inferior_reset_breakpoints the clone is set to enabled once it has been associated with the child process. With this, the bp_location 'inserted' member is maintained correctly throughout the follow-fork procedure and the behavior is as expected. The same treatment is given to the exception_resume_breakpoint when following a fork. Testing: Ran 'make check' on Linux x64. 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. 4) check that unfollowed, undetached inferiors can be resumed. gdb/ 2014-06-18 Don Breazeal <donb@codesourcery.com> * breakpoint.c (set_longjmp_breakpoint): Call momentary_breakpoint_from_master with additional argument. (set_longjmp_breakpoint_for_call_dummy): Call momentary_breakpoint_from_master with additional argument. (set_std_terminate_breakpoint): Call momentary_breakpoint_from_master with additional argument. (momentary_breakpoint_from_master): Add argument to function definition and use it to initialize structure member flag. (clone_momentary_breakpoint): Call momentary_breakpoint_from_master with additional argument. * infrun.c (follow_inferior_reset_breakpoints): Clear structure member flags set in momentary_breakpoint_from_master. gdb/testsuite/ 2014-06-18 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.
2014-06-18 17:25:47 +08:00
# Set up the output we expect to see after we run.
set expected_re ""
if {$who == "child"} {
Follow-fork message printing improvements This commit modifies the code that prints attach and detach messages related to following fork and vfork. The changes include using target_terminal_ours_for_output instead of target_terminal_ours, printing "vfork" instead of "fork" for all vfork-related messages, and using _() for the format strings of all of the messages. We also add a "detach" message for when a fork parent is detached. Previously in this case the only message was notification of attaching to the child. We still do not print any messages when following the parent and detaching the child (the default). The rationale for this is that from the user's perspective the new child was never attached. Note that all of these messages are only printed when 'verbose' is set or when debugging is turned on. The tests gdb.base/foll-fork.exp and gdb.base/foll-vfork.exp were modified to check for the new message. Tested on x64 Ubuntu Lucid, native only. gdb/ChangeLog: * infrun.c (follow_fork_inferior): Update fork message printing to use target_terminal_ours_for_output instead of target_terminal_ours, to use _() for all format strings, to print "vfork" instead of "fork" for vforks, and to add a detach message. (handle_vfork_child_exec_or_exit): Update message printing to use target_terminal_ours_for_output instead of target_terminal_ours, to use _() for all format strings, and to fix some formatting. gdb/testsuite/ChangeLog: * gdb.base/foll-fork.exp (test_follow_fork, catch_fork_child_follow): Check for updated fork messages emitted from infrun.c. * gdb.base/foll-vfork.exp (vfork_parent_follow_through_step, vfork_parent_follow_to_bp, vfork_and_exec_child_follow_to_main_bp, vfork_and_exec_child_follow_through_step): Check for updated vfork messages emitted from infrun.c.
2014-10-25 02:36:06 +08:00
set expected_re "Attaching after.* fork to.*"
if {$detach == "on"} {
append expected_re "Detaching after fork from .*"
}
append expected_re "set breakpoint here.*"
Symptom: Using the test program gdb.base/foll-fork.c, with follow-fork-mode set to "child" and detach-on-fork set to "off", stepping or running past the fork call results in the child process running to completion, when it should just finish the single step. In addition, the breakpoint is not removed from the parent process, so if it is resumed it receives a SIGTRAP. Cause: No matter what the setting for detach-on-fork, when stepping past a fork, the single-step breakpoint (step_resume_breakpoint) is not handled correctly in the parent. The SR breakpoint is cloned for the child process, but before the clone is associated with the child it is treated as a duplicate of the original, associated wth the parent. This results in the insertion state of the original SR breakpoint and the clone being "swapped" by breakpoint.c:update_global_location_list, so that the clone is marked as inserted. In the case where the parent is not detached, the two breakpoints remain in that state. The breakpoint is never inserted in the child, because although the cloned SR breakpoint is associated with the child, it is marked as inserted. When the child is resumed, it runs to completion. The breakpoint is never removed from the parent, so that if it is resumed after the child exits, it gets a SIGTRAP. Here is the sequence of events: 1) handle_inferior_event: FORK event is recognized. 2) handle_inferior_event: detach_breakpoints removes all breakpoints from the child. 3) follow_fork: the parent SR breakpoint is cloned. Part of this procedure is to call update_global_location_list, which swaps the insertion state of the original and cloned SR breakpoints as part of ensuring that duplicate breakpoints are only inserted once. At this point the original SR breakpoint is not marked as inserted, and the clone is. The breakpoint is actually inserted in the parent but not the child. 4) follow_fork: the original breakpoint is deleted by calling delete_step_resume_breakpoint. Since the original is not marked as inserted, the actual breakpoint remains in the parent process. update_global_location_list is called again as part of the deletion. The clone is still associated with the parent, but since it is marked as enabled and inserted, the breakpoint is left in the parent. 5) follow_fork: if detach-on-fork is 'on', the actual breakpoint will be removed from the parent in target_detach, based on the cloned breakpoint still associated with the parent. Then the clone is no longer marked as inserted. In follow_inferior_reset_breakpoints the clone is associated with the child, and can be inserted. If detach-on-fork is 'off', the actual breakpoint in the parent is never removed (although the breakpoint had been deleted from the list). Since the clone continues to be marked 'inserted', the SR breakpoint is never inserted in the child. Fix: Set the cloned breakpoint as disabled from the moment it is created. This is done by modifying clone_momentary_breakpoint to take an additional argument, LOC_ENABLED, which is used as the value of the bp_location->enabled member. The clone must be disabled at that point because clone_momentary_breakpoint calls update_global_location_list, which will swap treat the clone as a duplicate of the original breakpoint if it is enabled. All the calls to clone_momentary_breakpoint had to be modified to pass '1' or '0'. I looked at implementing an enum for the enabled member, but concluded that readability would suffer because there are so many places it is used as a boolean, e.g. "if (bl->enabled)". In follow_inferior_reset_breakpoints the clone is set to enabled once it has been associated with the child process. With this, the bp_location 'inserted' member is maintained correctly throughout the follow-fork procedure and the behavior is as expected. The same treatment is given to the exception_resume_breakpoint when following a fork. Testing: Ran 'make check' on Linux x64. 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. 4) check that unfollowed, undetached inferiors can be resumed. gdb/ 2014-06-18 Don Breazeal <donb@codesourcery.com> * breakpoint.c (set_longjmp_breakpoint): Call momentary_breakpoint_from_master with additional argument. (set_longjmp_breakpoint_for_call_dummy): Call momentary_breakpoint_from_master with additional argument. (set_std_terminate_breakpoint): Call momentary_breakpoint_from_master with additional argument. (momentary_breakpoint_from_master): Add argument to function definition and use it to initialize structure member flag. (clone_momentary_breakpoint): Call momentary_breakpoint_from_master with additional argument. * infrun.c (follow_inferior_reset_breakpoints): Clear structure member flags set in momentary_breakpoint_from_master. gdb/testsuite/ 2014-06-18 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.
2014-06-18 17:25:47 +08:00
} elseif {$who == "parent" && $detach == "on"} {
set expected_re "Detaching after fork from .*set breakpoint here.*"
} else {
set expected_re ".*set breakpoint here.*"
}
Symptom: Using the test program gdb.base/foll-fork.c, with follow-fork-mode set to "child" and detach-on-fork set to "off", stepping or running past the fork call results in the child process running to completion, when it should just finish the single step. In addition, the breakpoint is not removed from the parent process, so if it is resumed it receives a SIGTRAP. Cause: No matter what the setting for detach-on-fork, when stepping past a fork, the single-step breakpoint (step_resume_breakpoint) is not handled correctly in the parent. The SR breakpoint is cloned for the child process, but before the clone is associated with the child it is treated as a duplicate of the original, associated wth the parent. This results in the insertion state of the original SR breakpoint and the clone being "swapped" by breakpoint.c:update_global_location_list, so that the clone is marked as inserted. In the case where the parent is not detached, the two breakpoints remain in that state. The breakpoint is never inserted in the child, because although the cloned SR breakpoint is associated with the child, it is marked as inserted. When the child is resumed, it runs to completion. The breakpoint is never removed from the parent, so that if it is resumed after the child exits, it gets a SIGTRAP. Here is the sequence of events: 1) handle_inferior_event: FORK event is recognized. 2) handle_inferior_event: detach_breakpoints removes all breakpoints from the child. 3) follow_fork: the parent SR breakpoint is cloned. Part of this procedure is to call update_global_location_list, which swaps the insertion state of the original and cloned SR breakpoints as part of ensuring that duplicate breakpoints are only inserted once. At this point the original SR breakpoint is not marked as inserted, and the clone is. The breakpoint is actually inserted in the parent but not the child. 4) follow_fork: the original breakpoint is deleted by calling delete_step_resume_breakpoint. Since the original is not marked as inserted, the actual breakpoint remains in the parent process. update_global_location_list is called again as part of the deletion. The clone is still associated with the parent, but since it is marked as enabled and inserted, the breakpoint is left in the parent. 5) follow_fork: if detach-on-fork is 'on', the actual breakpoint will be removed from the parent in target_detach, based on the cloned breakpoint still associated with the parent. Then the clone is no longer marked as inserted. In follow_inferior_reset_breakpoints the clone is associated with the child, and can be inserted. If detach-on-fork is 'off', the actual breakpoint in the parent is never removed (although the breakpoint had been deleted from the list). Since the clone continues to be marked 'inserted', the SR breakpoint is never inserted in the child. Fix: Set the cloned breakpoint as disabled from the moment it is created. This is done by modifying clone_momentary_breakpoint to take an additional argument, LOC_ENABLED, which is used as the value of the bp_location->enabled member. The clone must be disabled at that point because clone_momentary_breakpoint calls update_global_location_list, which will swap treat the clone as a duplicate of the original breakpoint if it is enabled. All the calls to clone_momentary_breakpoint had to be modified to pass '1' or '0'. I looked at implementing an enum for the enabled member, but concluded that readability would suffer because there are so many places it is used as a boolean, e.g. "if (bl->enabled)". In follow_inferior_reset_breakpoints the clone is set to enabled once it has been associated with the child process. With this, the bp_location 'inserted' member is maintained correctly throughout the follow-fork procedure and the behavior is as expected. The same treatment is given to the exception_resume_breakpoint when following a fork. Testing: Ran 'make check' on Linux x64. 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. 4) check that unfollowed, undetached inferiors can be resumed. gdb/ 2014-06-18 Don Breazeal <donb@codesourcery.com> * breakpoint.c (set_longjmp_breakpoint): Call momentary_breakpoint_from_master with additional argument. (set_longjmp_breakpoint_for_call_dummy): Call momentary_breakpoint_from_master with additional argument. (set_std_terminate_breakpoint): Call momentary_breakpoint_from_master with additional argument. (momentary_breakpoint_from_master): Add argument to function definition and use it to initialize structure member flag. (clone_momentary_breakpoint): Call momentary_breakpoint_from_master with additional argument. * infrun.c (follow_inferior_reset_breakpoints): Clear structure member flags set in momentary_breakpoint_from_master. gdb/testsuite/ 2014-06-18 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.
2014-06-18 17:25:47 +08:00
# Test running past and following the fork, using the parameters
# set above.
gdb_test $cmd $expected_re "$cmd past fork"
Symptom: Using the test program gdb.base/foll-fork.c, with follow-fork-mode set to "child" and detach-on-fork set to "off", stepping or running past the fork call results in the child process running to completion, when it should just finish the single step. In addition, the breakpoint is not removed from the parent process, so if it is resumed it receives a SIGTRAP. Cause: No matter what the setting for detach-on-fork, when stepping past a fork, the single-step breakpoint (step_resume_breakpoint) is not handled correctly in the parent. The SR breakpoint is cloned for the child process, but before the clone is associated with the child it is treated as a duplicate of the original, associated wth the parent. This results in the insertion state of the original SR breakpoint and the clone being "swapped" by breakpoint.c:update_global_location_list, so that the clone is marked as inserted. In the case where the parent is not detached, the two breakpoints remain in that state. The breakpoint is never inserted in the child, because although the cloned SR breakpoint is associated with the child, it is marked as inserted. When the child is resumed, it runs to completion. The breakpoint is never removed from the parent, so that if it is resumed after the child exits, it gets a SIGTRAP. Here is the sequence of events: 1) handle_inferior_event: FORK event is recognized. 2) handle_inferior_event: detach_breakpoints removes all breakpoints from the child. 3) follow_fork: the parent SR breakpoint is cloned. Part of this procedure is to call update_global_location_list, which swaps the insertion state of the original and cloned SR breakpoints as part of ensuring that duplicate breakpoints are only inserted once. At this point the original SR breakpoint is not marked as inserted, and the clone is. The breakpoint is actually inserted in the parent but not the child. 4) follow_fork: the original breakpoint is deleted by calling delete_step_resume_breakpoint. Since the original is not marked as inserted, the actual breakpoint remains in the parent process. update_global_location_list is called again as part of the deletion. The clone is still associated with the parent, but since it is marked as enabled and inserted, the breakpoint is left in the parent. 5) follow_fork: if detach-on-fork is 'on', the actual breakpoint will be removed from the parent in target_detach, based on the cloned breakpoint still associated with the parent. Then the clone is no longer marked as inserted. In follow_inferior_reset_breakpoints the clone is associated with the child, and can be inserted. If detach-on-fork is 'off', the actual breakpoint in the parent is never removed (although the breakpoint had been deleted from the list). Since the clone continues to be marked 'inserted', the SR breakpoint is never inserted in the child. Fix: Set the cloned breakpoint as disabled from the moment it is created. This is done by modifying clone_momentary_breakpoint to take an additional argument, LOC_ENABLED, which is used as the value of the bp_location->enabled member. The clone must be disabled at that point because clone_momentary_breakpoint calls update_global_location_list, which will swap treat the clone as a duplicate of the original breakpoint if it is enabled. All the calls to clone_momentary_breakpoint had to be modified to pass '1' or '0'. I looked at implementing an enum for the enabled member, but concluded that readability would suffer because there are so many places it is used as a boolean, e.g. "if (bl->enabled)". In follow_inferior_reset_breakpoints the clone is set to enabled once it has been associated with the child process. With this, the bp_location 'inserted' member is maintained correctly throughout the follow-fork procedure and the behavior is as expected. The same treatment is given to the exception_resume_breakpoint when following a fork. Testing: Ran 'make check' on Linux x64. 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. 4) check that unfollowed, undetached inferiors can be resumed. gdb/ 2014-06-18 Don Breazeal <donb@codesourcery.com> * breakpoint.c (set_longjmp_breakpoint): Call momentary_breakpoint_from_master with additional argument. (set_longjmp_breakpoint_for_call_dummy): Call momentary_breakpoint_from_master with additional argument. (set_std_terminate_breakpoint): Call momentary_breakpoint_from_master with additional argument. (momentary_breakpoint_from_master): Add argument to function definition and use it to initialize structure member flag. (clone_momentary_breakpoint): Call momentary_breakpoint_from_master with additional argument. * infrun.c (follow_inferior_reset_breakpoints): Clear structure member flags set in momentary_breakpoint_from_master. gdb/testsuite/ 2014-06-18 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.
2014-06-18 17:25:47 +08:00
# Check that we have the inferiors arranged correctly after
# following the fork.
set resume_unfollowed 0
if {$who == "parent" && $detach == "on"} {
Symptom: Using the test program gdb.base/foll-fork.c, with follow-fork-mode set to "child" and detach-on-fork set to "off", stepping or running past the fork call results in the child process running to completion, when it should just finish the single step. In addition, the breakpoint is not removed from the parent process, so if it is resumed it receives a SIGTRAP. Cause: No matter what the setting for detach-on-fork, when stepping past a fork, the single-step breakpoint (step_resume_breakpoint) is not handled correctly in the parent. The SR breakpoint is cloned for the child process, but before the clone is associated with the child it is treated as a duplicate of the original, associated wth the parent. This results in the insertion state of the original SR breakpoint and the clone being "swapped" by breakpoint.c:update_global_location_list, so that the clone is marked as inserted. In the case where the parent is not detached, the two breakpoints remain in that state. The breakpoint is never inserted in the child, because although the cloned SR breakpoint is associated with the child, it is marked as inserted. When the child is resumed, it runs to completion. The breakpoint is never removed from the parent, so that if it is resumed after the child exits, it gets a SIGTRAP. Here is the sequence of events: 1) handle_inferior_event: FORK event is recognized. 2) handle_inferior_event: detach_breakpoints removes all breakpoints from the child. 3) follow_fork: the parent SR breakpoint is cloned. Part of this procedure is to call update_global_location_list, which swaps the insertion state of the original and cloned SR breakpoints as part of ensuring that duplicate breakpoints are only inserted once. At this point the original SR breakpoint is not marked as inserted, and the clone is. The breakpoint is actually inserted in the parent but not the child. 4) follow_fork: the original breakpoint is deleted by calling delete_step_resume_breakpoint. Since the original is not marked as inserted, the actual breakpoint remains in the parent process. update_global_location_list is called again as part of the deletion. The clone is still associated with the parent, but since it is marked as enabled and inserted, the breakpoint is left in the parent. 5) follow_fork: if detach-on-fork is 'on', the actual breakpoint will be removed from the parent in target_detach, based on the cloned breakpoint still associated with the parent. Then the clone is no longer marked as inserted. In follow_inferior_reset_breakpoints the clone is associated with the child, and can be inserted. If detach-on-fork is 'off', the actual breakpoint in the parent is never removed (although the breakpoint had been deleted from the list). Since the clone continues to be marked 'inserted', the SR breakpoint is never inserted in the child. Fix: Set the cloned breakpoint as disabled from the moment it is created. This is done by modifying clone_momentary_breakpoint to take an additional argument, LOC_ENABLED, which is used as the value of the bp_location->enabled member. The clone must be disabled at that point because clone_momentary_breakpoint calls update_global_location_list, which will swap treat the clone as a duplicate of the original breakpoint if it is enabled. All the calls to clone_momentary_breakpoint had to be modified to pass '1' or '0'. I looked at implementing an enum for the enabled member, but concluded that readability would suffer because there are so many places it is used as a boolean, e.g. "if (bl->enabled)". In follow_inferior_reset_breakpoints the clone is set to enabled once it has been associated with the child process. With this, the bp_location 'inserted' member is maintained correctly throughout the follow-fork procedure and the behavior is as expected. The same treatment is given to the exception_resume_breakpoint when following a fork. Testing: Ran 'make check' on Linux x64. 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. 4) check that unfollowed, undetached inferiors can be resumed. gdb/ 2014-06-18 Don Breazeal <donb@codesourcery.com> * breakpoint.c (set_longjmp_breakpoint): Call momentary_breakpoint_from_master with additional argument. (set_longjmp_breakpoint_for_call_dummy): Call momentary_breakpoint_from_master with additional argument. (set_std_terminate_breakpoint): Call momentary_breakpoint_from_master with additional argument. (momentary_breakpoint_from_master): Add argument to function definition and use it to initialize structure member flag. (clone_momentary_breakpoint): Call momentary_breakpoint_from_master with additional argument. * infrun.c (follow_inferior_reset_breakpoints): Clear structure member flags set in momentary_breakpoint_from_master. gdb/testsuite/ 2014-06-18 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.
2014-06-18 17:25:47 +08:00
# Follow parent / detach child: the only inferior is the parent.
gdb_test "info inferiors" "\\* 1 .* process.*" \
"info inferiors"
Symptom: Using the test program gdb.base/foll-fork.c, with follow-fork-mode set to "child" and detach-on-fork set to "off", stepping or running past the fork call results in the child process running to completion, when it should just finish the single step. In addition, the breakpoint is not removed from the parent process, so if it is resumed it receives a SIGTRAP. Cause: No matter what the setting for detach-on-fork, when stepping past a fork, the single-step breakpoint (step_resume_breakpoint) is not handled correctly in the parent. The SR breakpoint is cloned for the child process, but before the clone is associated with the child it is treated as a duplicate of the original, associated wth the parent. This results in the insertion state of the original SR breakpoint and the clone being "swapped" by breakpoint.c:update_global_location_list, so that the clone is marked as inserted. In the case where the parent is not detached, the two breakpoints remain in that state. The breakpoint is never inserted in the child, because although the cloned SR breakpoint is associated with the child, it is marked as inserted. When the child is resumed, it runs to completion. The breakpoint is never removed from the parent, so that if it is resumed after the child exits, it gets a SIGTRAP. Here is the sequence of events: 1) handle_inferior_event: FORK event is recognized. 2) handle_inferior_event: detach_breakpoints removes all breakpoints from the child. 3) follow_fork: the parent SR breakpoint is cloned. Part of this procedure is to call update_global_location_list, which swaps the insertion state of the original and cloned SR breakpoints as part of ensuring that duplicate breakpoints are only inserted once. At this point the original SR breakpoint is not marked as inserted, and the clone is. The breakpoint is actually inserted in the parent but not the child. 4) follow_fork: the original breakpoint is deleted by calling delete_step_resume_breakpoint. Since the original is not marked as inserted, the actual breakpoint remains in the parent process. update_global_location_list is called again as part of the deletion. The clone is still associated with the parent, but since it is marked as enabled and inserted, the breakpoint is left in the parent. 5) follow_fork: if detach-on-fork is 'on', the actual breakpoint will be removed from the parent in target_detach, based on the cloned breakpoint still associated with the parent. Then the clone is no longer marked as inserted. In follow_inferior_reset_breakpoints the clone is associated with the child, and can be inserted. If detach-on-fork is 'off', the actual breakpoint in the parent is never removed (although the breakpoint had been deleted from the list). Since the clone continues to be marked 'inserted', the SR breakpoint is never inserted in the child. Fix: Set the cloned breakpoint as disabled from the moment it is created. This is done by modifying clone_momentary_breakpoint to take an additional argument, LOC_ENABLED, which is used as the value of the bp_location->enabled member. The clone must be disabled at that point because clone_momentary_breakpoint calls update_global_location_list, which will swap treat the clone as a duplicate of the original breakpoint if it is enabled. All the calls to clone_momentary_breakpoint had to be modified to pass '1' or '0'. I looked at implementing an enum for the enabled member, but concluded that readability would suffer because there are so many places it is used as a boolean, e.g. "if (bl->enabled)". In follow_inferior_reset_breakpoints the clone is set to enabled once it has been associated with the child process. With this, the bp_location 'inserted' member is maintained correctly throughout the follow-fork procedure and the behavior is as expected. The same treatment is given to the exception_resume_breakpoint when following a fork. Testing: Ran 'make check' on Linux x64. 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. 4) check that unfollowed, undetached inferiors can be resumed. gdb/ 2014-06-18 Don Breazeal <donb@codesourcery.com> * breakpoint.c (set_longjmp_breakpoint): Call momentary_breakpoint_from_master with additional argument. (set_longjmp_breakpoint_for_call_dummy): Call momentary_breakpoint_from_master with additional argument. (set_std_terminate_breakpoint): Call momentary_breakpoint_from_master with additional argument. (momentary_breakpoint_from_master): Add argument to function definition and use it to initialize structure member flag. (clone_momentary_breakpoint): Call momentary_breakpoint_from_master with additional argument. * infrun.c (follow_inferior_reset_breakpoints): Clear structure member flags set in momentary_breakpoint_from_master. gdb/testsuite/ 2014-06-18 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.
2014-06-18 17:25:47 +08:00
} elseif {$who == "parent" && $detach == "off"} {
# Follow parent / keep child: two inferiors under debug, the
# parent is the current inferior.
gdb_test "info inferiors" " 2 .*process.*\\* 1 .*process.*" \
"info inferiors"
gdb_test "inferior 2" "Switching to inferior 2 .*"
set resume_unfollowed 1
} 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 inferiors" "\\* 2 .*process.* 1 .*<null>.*" \
"info inferiors"
} elseif {$who == "child" && $detach == "off"} {
# Follow child / keep parent: two inferiors under debug, the
# child is the current inferior.
gdb_test "info inferiors" "\\* 2 .*process.* 1 .*process.*" \
"info inferiors"
gdb_test "inferior 1" "Switching to inferior 1 .*"
set resume_unfollowed 1
}
if {$resume_unfollowed == 1} {
if {$cmd == "next 2"} {
gdb_continue_to_end "continue unfollowed inferior to end"
} elseif {$cmd == "continue"} {
gdb_continue_to_breakpoint \
"continue unfollowed inferior to bp" \
".* set breakpoint here.*"
}
}
}
1999-06-29 07:04:32 +08:00
}
proc catch_fork_child_follow {} {
global gdb_prompt
global srcfile
set bp_after_fork [gdb_get_line_number "set breakpoint here"]
gdb_test "catch fork" "Catchpoint \[0-9\]* \\(fork\\)" \
"explicit child follow, set catch fork"
# Verify that the catchpoint is mentioned in an "info breakpoints",
# and further that the catchpoint mentions no process id.
#
set test_name "info shows catchpoint without pid"
gdb_test_multiple "info breakpoints" "$test_name" {
-re ".*catchpoint.*keep y.*fork\[\r\n\]+$gdb_prompt $" {
pass "$test_name"
}
}
gdb_test "continue" \
"Catchpoint \[0-9\]* \\(forked process \[0-9\]*\\),.*" \
"explicit child follow, catch fork"
# Verify that the catchpoint is mentioned in an "info breakpoints",
# and further that the catchpoint managed to capture a process id.
#
set test_name "info shows catchpoint without pid"
gdb_test_multiple "info breakpoints" "$test_name" {
-re ".*catchpoint.*keep y.*fork, process.*$gdb_prompt $" {
pass "$test_name"
}
}
gdb_test_no_output "set follow-fork child"
gdb_test "tbreak ${srcfile}:$bp_after_fork" \
"Temporary breakpoint.*, line $bp_after_fork.*" \
"set follow-fork child, tbreak"
Follow-fork message printing improvements This commit modifies the code that prints attach and detach messages related to following fork and vfork. The changes include using target_terminal_ours_for_output instead of target_terminal_ours, printing "vfork" instead of "fork" for all vfork-related messages, and using _() for the format strings of all of the messages. We also add a "detach" message for when a fork parent is detached. Previously in this case the only message was notification of attaching to the child. We still do not print any messages when following the parent and detaching the child (the default). The rationale for this is that from the user's perspective the new child was never attached. Note that all of these messages are only printed when 'verbose' is set or when debugging is turned on. The tests gdb.base/foll-fork.exp and gdb.base/foll-vfork.exp were modified to check for the new message. Tested on x64 Ubuntu Lucid, native only. gdb/ChangeLog: * infrun.c (follow_fork_inferior): Update fork message printing to use target_terminal_ours_for_output instead of target_terminal_ours, to use _() for all format strings, to print "vfork" instead of "fork" for vforks, and to add a detach message. (handle_vfork_child_exec_or_exit): Update message printing to use target_terminal_ours_for_output instead of target_terminal_ours, to use _() for all format strings, and to fix some formatting. gdb/testsuite/ChangeLog: * gdb.base/foll-fork.exp (test_follow_fork, catch_fork_child_follow): Check for updated fork messages emitted from infrun.c. * gdb.base/foll-vfork.exp (vfork_parent_follow_through_step, vfork_parent_follow_to_bp, vfork_and_exec_child_follow_to_main_bp, vfork_and_exec_child_follow_through_step): Check for updated vfork messages emitted from infrun.c.
2014-10-25 02:36:06 +08:00
set expected_re "Attaching after.* fork to.*Detaching after fork from"
append expected_re ".* at .*$bp_after_fork.*"
gdb_test "continue" $expected_re "set follow-fork child, hit tbreak"
# The parent 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
gdb_test "delete breakpoints" \
"" \
"set follow-fork child, cleanup" \
2011-09-29 22:13:00 +08:00
"Delete all breakpoints. \\(y or n\\) $" \
"y"
1999-06-29 07:04:32 +08:00
}
proc catch_fork_unpatch_child {} {
global gdb_prompt
global srcfile
set bp_exit [gdb_get_line_number "at exit"]
gdb_test "break callee" "file .*$srcfile, line .*" \
"unpatch child, break at callee"
gdb_test "catch fork" "Catchpoint \[0-9\]* \\(fork\\)" \
"unpatch child, set catch fork"
gdb_test "continue" \
"Catchpoint \[0-9\]* \\(forked process \[0-9\]*\\),.*" \
"unpatch child, catch fork"
# Delete all breakpoints and catchpoints.
delete_breakpoints
# Force $srcfile as the current GDB source can be in glibc sourcetree.
gdb_test "break $srcfile:$bp_exit" \
"Breakpoint .*file .*$srcfile, line .*" \
"unpatch child, breakpoint at exit call"
2010-06-01 Michael Snyder <msnyder@vmware.com> * gdb.base/arithmet.exp: Use gdb_test_no_output. * gdb.base/arrayidx.exp: Ditto. * gdb.base/attach.exp: Ditto. * gdb.base/auxv.exp: Ditto. * gdb.base/bigcre.exp: Ditto. * gdb.base/break-always.exp: Ditto. * gdb.base/break-interp.exp: Ditto. * gdb.base/break.exp: Ditto. * gdb.base/breakpoint-shadow.exp: Ditto. * gdb.base/call-ar-st.exp: Ditto. * gdb.base/call-sc.exp: Ditto. * gdb.base/call-signal-resume.exp: Ditto. * gdb.base/callfuncs.exp: Ditto. * gdb.base/catch-syscall.exp: Ditto. * gdb.base/charset.exp: Ditto. * gdb.base/code-expr.exp: Ditto. * gdb.base/commands.exp: Ditto. * gdb.base/cond-expr.exp: Ditto. * gdb.base/condbreak.exp: Ditto. * gdb.base/cursal.exp: Ditto. * gdb.base/cvexpr.exp: Ditto. * gdb.base/default.exp: Ditto. * gdb.base/del.exp: Ditto. * gdb.base/detach.exp: Ditto. * gdb.base/display.exp: Ditto. * gdb.base/ena-dis-br.exp: Ditto. * gdb.base/eval-skip.exp: Ditto. * gdb.base/foll-fork.exp: Ditto. * gdb.base/foll-vfork.exp: Ditto. * gdb.base/frame-args.exp: Ditto. * gdb.base/funcargs.exp: Ditto. * gdb.base/gcore-buffer-overflow.exp: Ditto. * gdb.base/gdbvars.exp: Ditto. * gdb.base/help.exp: Ditto. * gdb.base/ifelse.exp: Ditto. * gdb.base/included.exp: Ditto. * gdb.base/list.exp: Ditto. * gdb.base/macscp.exp: Ditto. * gdb.base/maint.exp: Ditto. * gdb.base/multi-fork.exp: Ditto. * gdb.base/overlays.exp: Ditto. * gdb.base/page.exp: Ditto. * gdb.base/pending.exp: Ditto. * gdb.base/pointers.exp: Ditto. * gdb.base/pr11022.exp: Ditto. * gdb.base/prelink.exp: Ditto. * gdb.base/printcmds.exp: Ditto. * gdb.base/psymtab.exp: Ditto. * gdb.base/randomize.exp: Ditto. * gdb.base/relational.exp: Ditto. * gdb.base/relocate.exp: Ditto. * gdb.base/remote.exp: Ditto. * gdb.base/sepdebug.exp: Ditto. * gdb.base/set-lang-auto.exp: Ditto. * gdb.base/setshow.exp: Ditto. * gdb.base/setvar.exp: Ditto. * gdb.base/signals.exp: Ditto. * gdb.base/signull.exp: Ditto. * gdb.base/sigstep.exp: Ditto. * gdb.base/sizeof.exp: Ditto. * gdb.base/solib-disc.exp: Ditto. * gdb.base/store.exp: Ditto. * gdb.base/structs.exp: Ditto. * gdb.base/structs2.exp: Ditto. * gdb.base/subst.exp: Ditto. * gdb.base/term.exp: Ditto. * gdb.base/trace-commands.exp: Ditto. * gdb.base/unwindonsignal.exp: Ditto. * gdb.base/valgrind-db-attach.exp: Ditto. * gdb.base/varargs.exp: Ditto. * gdb.base/watch-cond.exp: Ditto. * gdb.base/watch_thread_num.exp: Ditto. * gdb.base/watchpoint-cond-gone.exp: Ditto. * gdb.base/watchpoint.exp: Ditto. * gdb.base/whatis-exp.exp: Ditto.
2010-06-02 05:29:21 +08:00
gdb_test_no_output "set follow-fork child" \
"unpatch child, set follow-fork child"
set test "unpatch child, unpatched parent breakpoints from child"
gdb_test_multiple "continue" $test {
-re "at exit.*$gdb_prompt $" {
pass "$test"
}
-re "SIGTRAP.*$gdb_prompt $" {
fail "$test"
# Explicitly kill this child, so we can continue gracefully
# with further testing...
send_gdb "kill\n"
gdb_expect {
-re ".*Kill the program being debugged.*y or n. $" {
send_gdb "y\n"
gdb_expect -re "$gdb_prompt $" {}
}
}
}
}
}
1999-06-29 07:04:32 +08:00
proc tcatch_fork_parent_follow {} {
global gdb_prompt
global srcfile
set bp_after_fork [gdb_get_line_number "set breakpoint here"]
gdb_test "catch fork" "Catchpoint \[0-9\]* \\(fork\\)" \
"explicit parent follow, set tcatch fork"
1999-06-29 07:04:32 +08:00
# ??rehrauer: I don't yet know how to get the id of the tcatch
# via this script, so that I can add a -do list to it. For now,
# do the follow stuff after the catch happens.
gdb_test "continue" \
"Catchpoint \[0-9\]* \\(forked process \[0-9\]*\\),.*" \
"explicit parent follow, tcatch fork"
gdb_test_no_output "set follow-fork parent"
gdb_test "tbreak ${srcfile}:$bp_after_fork" \
"Temporary breakpoint.*, line $bp_after_fork.*" \
"set follow-fork parent, tbreak"
gdb_test "continue" \
"Detaching after fork from.* at .*$bp_after_fork.*" \
"set follow-fork parent, hit tbreak"
# 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
gdb_test "delete breakpoints" \
"" \
"set follow-fork parent, cleanup" \
2011-09-29 22:13:00 +08:00
"Delete all breakpoints. \\(y or n\\) $" \
"y"
1999-06-29 07:04:32 +08:00
}
proc do_fork_tests {} {
global gdb_prompt
Symptom: Using the test program gdb.base/foll-fork.c, with follow-fork-mode set to "child" and detach-on-fork set to "off", stepping or running past the fork call results in the child process running to completion, when it should just finish the single step. In addition, the breakpoint is not removed from the parent process, so if it is resumed it receives a SIGTRAP. Cause: No matter what the setting for detach-on-fork, when stepping past a fork, the single-step breakpoint (step_resume_breakpoint) is not handled correctly in the parent. The SR breakpoint is cloned for the child process, but before the clone is associated with the child it is treated as a duplicate of the original, associated wth the parent. This results in the insertion state of the original SR breakpoint and the clone being "swapped" by breakpoint.c:update_global_location_list, so that the clone is marked as inserted. In the case where the parent is not detached, the two breakpoints remain in that state. The breakpoint is never inserted in the child, because although the cloned SR breakpoint is associated with the child, it is marked as inserted. When the child is resumed, it runs to completion. The breakpoint is never removed from the parent, so that if it is resumed after the child exits, it gets a SIGTRAP. Here is the sequence of events: 1) handle_inferior_event: FORK event is recognized. 2) handle_inferior_event: detach_breakpoints removes all breakpoints from the child. 3) follow_fork: the parent SR breakpoint is cloned. Part of this procedure is to call update_global_location_list, which swaps the insertion state of the original and cloned SR breakpoints as part of ensuring that duplicate breakpoints are only inserted once. At this point the original SR breakpoint is not marked as inserted, and the clone is. The breakpoint is actually inserted in the parent but not the child. 4) follow_fork: the original breakpoint is deleted by calling delete_step_resume_breakpoint. Since the original is not marked as inserted, the actual breakpoint remains in the parent process. update_global_location_list is called again as part of the deletion. The clone is still associated with the parent, but since it is marked as enabled and inserted, the breakpoint is left in the parent. 5) follow_fork: if detach-on-fork is 'on', the actual breakpoint will be removed from the parent in target_detach, based on the cloned breakpoint still associated with the parent. Then the clone is no longer marked as inserted. In follow_inferior_reset_breakpoints the clone is associated with the child, and can be inserted. If detach-on-fork is 'off', the actual breakpoint in the parent is never removed (although the breakpoint had been deleted from the list). Since the clone continues to be marked 'inserted', the SR breakpoint is never inserted in the child. Fix: Set the cloned breakpoint as disabled from the moment it is created. This is done by modifying clone_momentary_breakpoint to take an additional argument, LOC_ENABLED, which is used as the value of the bp_location->enabled member. The clone must be disabled at that point because clone_momentary_breakpoint calls update_global_location_list, which will swap treat the clone as a duplicate of the original breakpoint if it is enabled. All the calls to clone_momentary_breakpoint had to be modified to pass '1' or '0'. I looked at implementing an enum for the enabled member, but concluded that readability would suffer because there are so many places it is used as a boolean, e.g. "if (bl->enabled)". In follow_inferior_reset_breakpoints the clone is set to enabled once it has been associated with the child process. With this, the bp_location 'inserted' member is maintained correctly throughout the follow-fork procedure and the behavior is as expected. The same treatment is given to the exception_resume_breakpoint when following a fork. Testing: Ran 'make check' on Linux x64. 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. 4) check that unfollowed, undetached inferiors can be resumed. gdb/ 2014-06-18 Don Breazeal <donb@codesourcery.com> * breakpoint.c (set_longjmp_breakpoint): Call momentary_breakpoint_from_master with additional argument. (set_longjmp_breakpoint_for_call_dummy): Call momentary_breakpoint_from_master with additional argument. (set_std_terminate_breakpoint): Call momentary_breakpoint_from_master with additional argument. (momentary_breakpoint_from_master): Add argument to function definition and use it to initialize structure member flag. (clone_momentary_breakpoint): Call momentary_breakpoint_from_master with additional argument. * infrun.c (follow_inferior_reset_breakpoints): Clear structure member flags set in momentary_breakpoint_from_master. gdb/testsuite/ 2014-06-18 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.
2014-06-18 17:25:47 +08:00
global testfile
1999-06-29 07:04:32 +08:00
# Verify that help is available for "set follow-fork-mode".
#
gdb_test "help set follow-fork-mode" \
"Set debugger response to a program call of fork or vfork..*
1999-06-29 07:04:32 +08:00
A fork or vfork creates a new process. follow-fork-mode can be:.*
.*parent - the original process is debugged after a fork.*
.*child - the new process is debugged after a fork.*
The unfollowed process will continue to run..*
By default, the debugger will follow the parent process..*" \
"help set follow-fork"
# Verify that we can set follow-fork-mode, using an abbreviation
# for both the flag and its value.
#
gdb_test_no_output "set follow-fork ch"
gdb_test "show follow-fork" \
"Debugger response to a program call of fork or vfork is \"child\".*" \
"set follow-fork, using abbreviations"
# Verify that we cannot set follow-fork-mode to nonsense.
#
gdb_test "set follow-fork chork" "Undefined item: \"chork\".*" \
"set follow-fork to nonsense is prohibited"
gdb_test_no_output "set follow-fork parent" "reset parent"
# Check that fork catchpoints are supported, as an indicator for whether
# fork-following is supported.
if [runto_main] then { check_fork_catchpoints }
Symptom: Using the test program gdb.base/foll-fork.c, with follow-fork-mode set to "child" and detach-on-fork set to "off", stepping or running past the fork call results in the child process running to completion, when it should just finish the single step. In addition, the breakpoint is not removed from the parent process, so if it is resumed it receives a SIGTRAP. Cause: No matter what the setting for detach-on-fork, when stepping past a fork, the single-step breakpoint (step_resume_breakpoint) is not handled correctly in the parent. The SR breakpoint is cloned for the child process, but before the clone is associated with the child it is treated as a duplicate of the original, associated wth the parent. This results in the insertion state of the original SR breakpoint and the clone being "swapped" by breakpoint.c:update_global_location_list, so that the clone is marked as inserted. In the case where the parent is not detached, the two breakpoints remain in that state. The breakpoint is never inserted in the child, because although the cloned SR breakpoint is associated with the child, it is marked as inserted. When the child is resumed, it runs to completion. The breakpoint is never removed from the parent, so that if it is resumed after the child exits, it gets a SIGTRAP. Here is the sequence of events: 1) handle_inferior_event: FORK event is recognized. 2) handle_inferior_event: detach_breakpoints removes all breakpoints from the child. 3) follow_fork: the parent SR breakpoint is cloned. Part of this procedure is to call update_global_location_list, which swaps the insertion state of the original and cloned SR breakpoints as part of ensuring that duplicate breakpoints are only inserted once. At this point the original SR breakpoint is not marked as inserted, and the clone is. The breakpoint is actually inserted in the parent but not the child. 4) follow_fork: the original breakpoint is deleted by calling delete_step_resume_breakpoint. Since the original is not marked as inserted, the actual breakpoint remains in the parent process. update_global_location_list is called again as part of the deletion. The clone is still associated with the parent, but since it is marked as enabled and inserted, the breakpoint is left in the parent. 5) follow_fork: if detach-on-fork is 'on', the actual breakpoint will be removed from the parent in target_detach, based on the cloned breakpoint still associated with the parent. Then the clone is no longer marked as inserted. In follow_inferior_reset_breakpoints the clone is associated with the child, and can be inserted. If detach-on-fork is 'off', the actual breakpoint in the parent is never removed (although the breakpoint had been deleted from the list). Since the clone continues to be marked 'inserted', the SR breakpoint is never inserted in the child. Fix: Set the cloned breakpoint as disabled from the moment it is created. This is done by modifying clone_momentary_breakpoint to take an additional argument, LOC_ENABLED, which is used as the value of the bp_location->enabled member. The clone must be disabled at that point because clone_momentary_breakpoint calls update_global_location_list, which will swap treat the clone as a duplicate of the original breakpoint if it is enabled. All the calls to clone_momentary_breakpoint had to be modified to pass '1' or '0'. I looked at implementing an enum for the enabled member, but concluded that readability would suffer because there are so many places it is used as a boolean, e.g. "if (bl->enabled)". In follow_inferior_reset_breakpoints the clone is set to enabled once it has been associated with the child process. With this, the bp_location 'inserted' member is maintained correctly throughout the follow-fork procedure and the behavior is as expected. The same treatment is given to the exception_resume_breakpoint when following a fork. Testing: Ran 'make check' on Linux x64. 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. 4) check that unfollowed, undetached inferiors can be resumed. gdb/ 2014-06-18 Don Breazeal <donb@codesourcery.com> * breakpoint.c (set_longjmp_breakpoint): Call momentary_breakpoint_from_master with additional argument. (set_longjmp_breakpoint_for_call_dummy): Call momentary_breakpoint_from_master with additional argument. (set_std_terminate_breakpoint): Call momentary_breakpoint_from_master with additional argument. (momentary_breakpoint_from_master): Add argument to function definition and use it to initialize structure member flag. (clone_momentary_breakpoint): Call momentary_breakpoint_from_master with additional argument. * infrun.c (follow_inferior_reset_breakpoints): Clear structure member flags set in momentary_breakpoint_from_master. gdb/testsuite/ 2014-06-18 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.
2014-06-18 17:25:47 +08:00
# Test the basic follow-fork functionality using all combinations of
# values for follow-fork-mode and detach-on-fork, using either a
# breakpoint or single-step to execute past the fork.
#
Symptom: Using the test program gdb.base/foll-fork.c, with follow-fork-mode set to "child" and detach-on-fork set to "off", stepping or running past the fork call results in the child process running to completion, when it should just finish the single step. In addition, the breakpoint is not removed from the parent process, so if it is resumed it receives a SIGTRAP. Cause: No matter what the setting for detach-on-fork, when stepping past a fork, the single-step breakpoint (step_resume_breakpoint) is not handled correctly in the parent. The SR breakpoint is cloned for the child process, but before the clone is associated with the child it is treated as a duplicate of the original, associated wth the parent. This results in the insertion state of the original SR breakpoint and the clone being "swapped" by breakpoint.c:update_global_location_list, so that the clone is marked as inserted. In the case where the parent is not detached, the two breakpoints remain in that state. The breakpoint is never inserted in the child, because although the cloned SR breakpoint is associated with the child, it is marked as inserted. When the child is resumed, it runs to completion. The breakpoint is never removed from the parent, so that if it is resumed after the child exits, it gets a SIGTRAP. Here is the sequence of events: 1) handle_inferior_event: FORK event is recognized. 2) handle_inferior_event: detach_breakpoints removes all breakpoints from the child. 3) follow_fork: the parent SR breakpoint is cloned. Part of this procedure is to call update_global_location_list, which swaps the insertion state of the original and cloned SR breakpoints as part of ensuring that duplicate breakpoints are only inserted once. At this point the original SR breakpoint is not marked as inserted, and the clone is. The breakpoint is actually inserted in the parent but not the child. 4) follow_fork: the original breakpoint is deleted by calling delete_step_resume_breakpoint. Since the original is not marked as inserted, the actual breakpoint remains in the parent process. update_global_location_list is called again as part of the deletion. The clone is still associated with the parent, but since it is marked as enabled and inserted, the breakpoint is left in the parent. 5) follow_fork: if detach-on-fork is 'on', the actual breakpoint will be removed from the parent in target_detach, based on the cloned breakpoint still associated with the parent. Then the clone is no longer marked as inserted. In follow_inferior_reset_breakpoints the clone is associated with the child, and can be inserted. If detach-on-fork is 'off', the actual breakpoint in the parent is never removed (although the breakpoint had been deleted from the list). Since the clone continues to be marked 'inserted', the SR breakpoint is never inserted in the child. Fix: Set the cloned breakpoint as disabled from the moment it is created. This is done by modifying clone_momentary_breakpoint to take an additional argument, LOC_ENABLED, which is used as the value of the bp_location->enabled member. The clone must be disabled at that point because clone_momentary_breakpoint calls update_global_location_list, which will swap treat the clone as a duplicate of the original breakpoint if it is enabled. All the calls to clone_momentary_breakpoint had to be modified to pass '1' or '0'. I looked at implementing an enum for the enabled member, but concluded that readability would suffer because there are so many places it is used as a boolean, e.g. "if (bl->enabled)". In follow_inferior_reset_breakpoints the clone is set to enabled once it has been associated with the child process. With this, the bp_location 'inserted' member is maintained correctly throughout the follow-fork procedure and the behavior is as expected. The same treatment is given to the exception_resume_breakpoint when following a fork. Testing: Ran 'make check' on Linux x64. 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. 4) check that unfollowed, undetached inferiors can be resumed. gdb/ 2014-06-18 Don Breazeal <donb@codesourcery.com> * breakpoint.c (set_longjmp_breakpoint): Call momentary_breakpoint_from_master with additional argument. (set_longjmp_breakpoint_for_call_dummy): Call momentary_breakpoint_from_master with additional argument. (set_std_terminate_breakpoint): Call momentary_breakpoint_from_master with additional argument. (momentary_breakpoint_from_master): Add argument to function definition and use it to initialize structure member flag. (clone_momentary_breakpoint): Call momentary_breakpoint_from_master with additional argument. * infrun.c (follow_inferior_reset_breakpoints): Clear structure member flags set in momentary_breakpoint_from_master. gdb/testsuite/ 2014-06-18 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.
2014-06-18 17:25:47 +08:00
# The first loop should be sufficient to test the defaults. There
# is no need to test using the defaults in other permutations (e.g.
# "default" "on", "parent" "default", etc.).
foreach cmd {"next 2" "continue"} {
test_follow_fork "default" "default" $cmd
}
Symptom: Using the test program gdb.base/foll-fork.c, with follow-fork-mode set to "child" and detach-on-fork set to "off", stepping or running past the fork call results in the child process running to completion, when it should just finish the single step. In addition, the breakpoint is not removed from the parent process, so if it is resumed it receives a SIGTRAP. Cause: No matter what the setting for detach-on-fork, when stepping past a fork, the single-step breakpoint (step_resume_breakpoint) is not handled correctly in the parent. The SR breakpoint is cloned for the child process, but before the clone is associated with the child it is treated as a duplicate of the original, associated wth the parent. This results in the insertion state of the original SR breakpoint and the clone being "swapped" by breakpoint.c:update_global_location_list, so that the clone is marked as inserted. In the case where the parent is not detached, the two breakpoints remain in that state. The breakpoint is never inserted in the child, because although the cloned SR breakpoint is associated with the child, it is marked as inserted. When the child is resumed, it runs to completion. The breakpoint is never removed from the parent, so that if it is resumed after the child exits, it gets a SIGTRAP. Here is the sequence of events: 1) handle_inferior_event: FORK event is recognized. 2) handle_inferior_event: detach_breakpoints removes all breakpoints from the child. 3) follow_fork: the parent SR breakpoint is cloned. Part of this procedure is to call update_global_location_list, which swaps the insertion state of the original and cloned SR breakpoints as part of ensuring that duplicate breakpoints are only inserted once. At this point the original SR breakpoint is not marked as inserted, and the clone is. The breakpoint is actually inserted in the parent but not the child. 4) follow_fork: the original breakpoint is deleted by calling delete_step_resume_breakpoint. Since the original is not marked as inserted, the actual breakpoint remains in the parent process. update_global_location_list is called again as part of the deletion. The clone is still associated with the parent, but since it is marked as enabled and inserted, the breakpoint is left in the parent. 5) follow_fork: if detach-on-fork is 'on', the actual breakpoint will be removed from the parent in target_detach, based on the cloned breakpoint still associated with the parent. Then the clone is no longer marked as inserted. In follow_inferior_reset_breakpoints the clone is associated with the child, and can be inserted. If detach-on-fork is 'off', the actual breakpoint in the parent is never removed (although the breakpoint had been deleted from the list). Since the clone continues to be marked 'inserted', the SR breakpoint is never inserted in the child. Fix: Set the cloned breakpoint as disabled from the moment it is created. This is done by modifying clone_momentary_breakpoint to take an additional argument, LOC_ENABLED, which is used as the value of the bp_location->enabled member. The clone must be disabled at that point because clone_momentary_breakpoint calls update_global_location_list, which will swap treat the clone as a duplicate of the original breakpoint if it is enabled. All the calls to clone_momentary_breakpoint had to be modified to pass '1' or '0'. I looked at implementing an enum for the enabled member, but concluded that readability would suffer because there are so many places it is used as a boolean, e.g. "if (bl->enabled)". In follow_inferior_reset_breakpoints the clone is set to enabled once it has been associated with the child process. With this, the bp_location 'inserted' member is maintained correctly throughout the follow-fork procedure and the behavior is as expected. The same treatment is given to the exception_resume_breakpoint when following a fork. Testing: Ran 'make check' on Linux x64. 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. 4) check that unfollowed, undetached inferiors can be resumed. gdb/ 2014-06-18 Don Breazeal <donb@codesourcery.com> * breakpoint.c (set_longjmp_breakpoint): Call momentary_breakpoint_from_master with additional argument. (set_longjmp_breakpoint_for_call_dummy): Call momentary_breakpoint_from_master with additional argument. (set_std_terminate_breakpoint): Call momentary_breakpoint_from_master with additional argument. (momentary_breakpoint_from_master): Add argument to function definition and use it to initialize structure member flag. (clone_momentary_breakpoint): Call momentary_breakpoint_from_master with additional argument. * infrun.c (follow_inferior_reset_breakpoints): Clear structure member flags set in momentary_breakpoint_from_master. gdb/testsuite/ 2014-06-18 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.
2014-06-18 17:25:47 +08:00
# Now test all explicit permutations.
foreach who {"parent" "child"} {
foreach detach {"on" "off"} {
foreach cmd {"next 2" "continue"} {
test_follow_fork $who $detach $cmd
}
}
}
Symptom: Using the test program gdb.base/foll-fork.c, with follow-fork-mode set to "child" and detach-on-fork set to "off", stepping or running past the fork call results in the child process running to completion, when it should just finish the single step. In addition, the breakpoint is not removed from the parent process, so if it is resumed it receives a SIGTRAP. Cause: No matter what the setting for detach-on-fork, when stepping past a fork, the single-step breakpoint (step_resume_breakpoint) is not handled correctly in the parent. The SR breakpoint is cloned for the child process, but before the clone is associated with the child it is treated as a duplicate of the original, associated wth the parent. This results in the insertion state of the original SR breakpoint and the clone being "swapped" by breakpoint.c:update_global_location_list, so that the clone is marked as inserted. In the case where the parent is not detached, the two breakpoints remain in that state. The breakpoint is never inserted in the child, because although the cloned SR breakpoint is associated with the child, it is marked as inserted. When the child is resumed, it runs to completion. The breakpoint is never removed from the parent, so that if it is resumed after the child exits, it gets a SIGTRAP. Here is the sequence of events: 1) handle_inferior_event: FORK event is recognized. 2) handle_inferior_event: detach_breakpoints removes all breakpoints from the child. 3) follow_fork: the parent SR breakpoint is cloned. Part of this procedure is to call update_global_location_list, which swaps the insertion state of the original and cloned SR breakpoints as part of ensuring that duplicate breakpoints are only inserted once. At this point the original SR breakpoint is not marked as inserted, and the clone is. The breakpoint is actually inserted in the parent but not the child. 4) follow_fork: the original breakpoint is deleted by calling delete_step_resume_breakpoint. Since the original is not marked as inserted, the actual breakpoint remains in the parent process. update_global_location_list is called again as part of the deletion. The clone is still associated with the parent, but since it is marked as enabled and inserted, the breakpoint is left in the parent. 5) follow_fork: if detach-on-fork is 'on', the actual breakpoint will be removed from the parent in target_detach, based on the cloned breakpoint still associated with the parent. Then the clone is no longer marked as inserted. In follow_inferior_reset_breakpoints the clone is associated with the child, and can be inserted. If detach-on-fork is 'off', the actual breakpoint in the parent is never removed (although the breakpoint had been deleted from the list). Since the clone continues to be marked 'inserted', the SR breakpoint is never inserted in the child. Fix: Set the cloned breakpoint as disabled from the moment it is created. This is done by modifying clone_momentary_breakpoint to take an additional argument, LOC_ENABLED, which is used as the value of the bp_location->enabled member. The clone must be disabled at that point because clone_momentary_breakpoint calls update_global_location_list, which will swap treat the clone as a duplicate of the original breakpoint if it is enabled. All the calls to clone_momentary_breakpoint had to be modified to pass '1' or '0'. I looked at implementing an enum for the enabled member, but concluded that readability would suffer because there are so many places it is used as a boolean, e.g. "if (bl->enabled)". In follow_inferior_reset_breakpoints the clone is set to enabled once it has been associated with the child process. With this, the bp_location 'inserted' member is maintained correctly throughout the follow-fork procedure and the behavior is as expected. The same treatment is given to the exception_resume_breakpoint when following a fork. Testing: Ran 'make check' on Linux x64. 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. 4) check that unfollowed, undetached inferiors can be resumed. gdb/ 2014-06-18 Don Breazeal <donb@codesourcery.com> * breakpoint.c (set_longjmp_breakpoint): Call momentary_breakpoint_from_master with additional argument. (set_longjmp_breakpoint_for_call_dummy): Call momentary_breakpoint_from_master with additional argument. (set_std_terminate_breakpoint): Call momentary_breakpoint_from_master with additional argument. (momentary_breakpoint_from_master): Add argument to function definition and use it to initialize structure member flag. (clone_momentary_breakpoint): Call momentary_breakpoint_from_master with additional argument. * infrun.c (follow_inferior_reset_breakpoints): Clear structure member flags set in momentary_breakpoint_from_master. gdb/testsuite/ 2014-06-18 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.
2014-06-18 17:25:47 +08:00
# Catchpoint tests.
Symptom: Using the test program gdb.base/foll-fork.c, with follow-fork-mode set to "child" and detach-on-fork set to "off", stepping or running past the fork call results in the child process running to completion, when it should just finish the single step. In addition, the breakpoint is not removed from the parent process, so if it is resumed it receives a SIGTRAP. Cause: No matter what the setting for detach-on-fork, when stepping past a fork, the single-step breakpoint (step_resume_breakpoint) is not handled correctly in the parent. The SR breakpoint is cloned for the child process, but before the clone is associated with the child it is treated as a duplicate of the original, associated wth the parent. This results in the insertion state of the original SR breakpoint and the clone being "swapped" by breakpoint.c:update_global_location_list, so that the clone is marked as inserted. In the case where the parent is not detached, the two breakpoints remain in that state. The breakpoint is never inserted in the child, because although the cloned SR breakpoint is associated with the child, it is marked as inserted. When the child is resumed, it runs to completion. The breakpoint is never removed from the parent, so that if it is resumed after the child exits, it gets a SIGTRAP. Here is the sequence of events: 1) handle_inferior_event: FORK event is recognized. 2) handle_inferior_event: detach_breakpoints removes all breakpoints from the child. 3) follow_fork: the parent SR breakpoint is cloned. Part of this procedure is to call update_global_location_list, which swaps the insertion state of the original and cloned SR breakpoints as part of ensuring that duplicate breakpoints are only inserted once. At this point the original SR breakpoint is not marked as inserted, and the clone is. The breakpoint is actually inserted in the parent but not the child. 4) follow_fork: the original breakpoint is deleted by calling delete_step_resume_breakpoint. Since the original is not marked as inserted, the actual breakpoint remains in the parent process. update_global_location_list is called again as part of the deletion. The clone is still associated with the parent, but since it is marked as enabled and inserted, the breakpoint is left in the parent. 5) follow_fork: if detach-on-fork is 'on', the actual breakpoint will be removed from the parent in target_detach, based on the cloned breakpoint still associated with the parent. Then the clone is no longer marked as inserted. In follow_inferior_reset_breakpoints the clone is associated with the child, and can be inserted. If detach-on-fork is 'off', the actual breakpoint in the parent is never removed (although the breakpoint had been deleted from the list). Since the clone continues to be marked 'inserted', the SR breakpoint is never inserted in the child. Fix: Set the cloned breakpoint as disabled from the moment it is created. This is done by modifying clone_momentary_breakpoint to take an additional argument, LOC_ENABLED, which is used as the value of the bp_location->enabled member. The clone must be disabled at that point because clone_momentary_breakpoint calls update_global_location_list, which will swap treat the clone as a duplicate of the original breakpoint if it is enabled. All the calls to clone_momentary_breakpoint had to be modified to pass '1' or '0'. I looked at implementing an enum for the enabled member, but concluded that readability would suffer because there are so many places it is used as a boolean, e.g. "if (bl->enabled)". In follow_inferior_reset_breakpoints the clone is set to enabled once it has been associated with the child process. With this, the bp_location 'inserted' member is maintained correctly throughout the follow-fork procedure and the behavior is as expected. The same treatment is given to the exception_resume_breakpoint when following a fork. Testing: Ran 'make check' on Linux x64. 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. 4) check that unfollowed, undetached inferiors can be resumed. gdb/ 2014-06-18 Don Breazeal <donb@codesourcery.com> * breakpoint.c (set_longjmp_breakpoint): Call momentary_breakpoint_from_master with additional argument. (set_longjmp_breakpoint_for_call_dummy): Call momentary_breakpoint_from_master with additional argument. (set_std_terminate_breakpoint): Call momentary_breakpoint_from_master with additional argument. (momentary_breakpoint_from_master): Add argument to function definition and use it to initialize structure member flag. (clone_momentary_breakpoint): Call momentary_breakpoint_from_master with additional argument. * infrun.c (follow_inferior_reset_breakpoints): Clear structure member flags set in momentary_breakpoint_from_master. gdb/testsuite/ 2014-06-18 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.
2014-06-18 17:25:47 +08:00
# 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.
#
if [runto_main] then { catch_fork_child_follow }
# Test that parent breakpoints are successfully detached from the
# child at fork time, even if the user removes them from the
# breakpoints list after stopping at a fork catchpoint.
if [runto_main] then { catch_fork_unpatch_child }
# Test the ability to catch a fork, specify via a -do clause that
# the parent be followed, and continue. Make the catchpoint temporary.
#
if [runto_main] then { tcatch_fork_parent_follow }
1999-06-29 07:04:32 +08:00
}
# The "Detaching..." and "Attaching..." messages may be hidden by
# default.
2010-06-01 Michael Snyder <msnyder@vmware.com> * gdb.base/arithmet.exp: Use gdb_test_no_output. * gdb.base/arrayidx.exp: Ditto. * gdb.base/attach.exp: Ditto. * gdb.base/auxv.exp: Ditto. * gdb.base/bigcre.exp: Ditto. * gdb.base/break-always.exp: Ditto. * gdb.base/break-interp.exp: Ditto. * gdb.base/break.exp: Ditto. * gdb.base/breakpoint-shadow.exp: Ditto. * gdb.base/call-ar-st.exp: Ditto. * gdb.base/call-sc.exp: Ditto. * gdb.base/call-signal-resume.exp: Ditto. * gdb.base/callfuncs.exp: Ditto. * gdb.base/catch-syscall.exp: Ditto. * gdb.base/charset.exp: Ditto. * gdb.base/code-expr.exp: Ditto. * gdb.base/commands.exp: Ditto. * gdb.base/cond-expr.exp: Ditto. * gdb.base/condbreak.exp: Ditto. * gdb.base/cursal.exp: Ditto. * gdb.base/cvexpr.exp: Ditto. * gdb.base/default.exp: Ditto. * gdb.base/del.exp: Ditto. * gdb.base/detach.exp: Ditto. * gdb.base/display.exp: Ditto. * gdb.base/ena-dis-br.exp: Ditto. * gdb.base/eval-skip.exp: Ditto. * gdb.base/foll-fork.exp: Ditto. * gdb.base/foll-vfork.exp: Ditto. * gdb.base/frame-args.exp: Ditto. * gdb.base/funcargs.exp: Ditto. * gdb.base/gcore-buffer-overflow.exp: Ditto. * gdb.base/gdbvars.exp: Ditto. * gdb.base/help.exp: Ditto. * gdb.base/ifelse.exp: Ditto. * gdb.base/included.exp: Ditto. * gdb.base/list.exp: Ditto. * gdb.base/macscp.exp: Ditto. * gdb.base/maint.exp: Ditto. * gdb.base/multi-fork.exp: Ditto. * gdb.base/overlays.exp: Ditto. * gdb.base/page.exp: Ditto. * gdb.base/pending.exp: Ditto. * gdb.base/pointers.exp: Ditto. * gdb.base/pr11022.exp: Ditto. * gdb.base/prelink.exp: Ditto. * gdb.base/printcmds.exp: Ditto. * gdb.base/psymtab.exp: Ditto. * gdb.base/randomize.exp: Ditto. * gdb.base/relational.exp: Ditto. * gdb.base/relocate.exp: Ditto. * gdb.base/remote.exp: Ditto. * gdb.base/sepdebug.exp: Ditto. * gdb.base/set-lang-auto.exp: Ditto. * gdb.base/setshow.exp: Ditto. * gdb.base/setvar.exp: Ditto. * gdb.base/signals.exp: Ditto. * gdb.base/signull.exp: Ditto. * gdb.base/sigstep.exp: Ditto. * gdb.base/sizeof.exp: Ditto. * gdb.base/solib-disc.exp: Ditto. * gdb.base/store.exp: Ditto. * gdb.base/structs.exp: Ditto. * gdb.base/structs2.exp: Ditto. * gdb.base/subst.exp: Ditto. * gdb.base/term.exp: Ditto. * gdb.base/trace-commands.exp: Ditto. * gdb.base/unwindonsignal.exp: Ditto. * gdb.base/valgrind-db-attach.exp: Ditto. * gdb.base/varargs.exp: Ditto. * gdb.base/watch-cond.exp: Ditto. * gdb.base/watch_thread_num.exp: Ditto. * gdb.base/watchpoint-cond-gone.exp: Ditto. * gdb.base/watchpoint.exp: Ditto. * gdb.base/whatis-exp.exp: Ditto.
2010-06-02 05:29:21 +08:00
gdb_test_no_output "set verbose"
1999-06-29 07:04:32 +08:00
# This is a test of gdb's ability to follow the parent, child or both
# parent and child of a Unix fork() system call.
#
do_fork_tests
return 0