mirror of
https://sourceware.org/git/binutils-gdb.git
synced 2025-03-07 13:39:43 +08:00
a1aa2221cb
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. |
||
|---|---|---|
| bfd | ||
| binutils | ||
| config | ||
| cpu | ||
| elfcpp | ||
| etc | ||
| gas | ||
| gdb | ||
| gold | ||
| gprof | ||
| include | ||
| intl | ||
| ld | ||
| libdecnumber | ||
| libiberty | ||
| opcodes | ||
| readline | ||
| sim | ||
| texinfo | ||
| .cvsignore | ||
| .gitignore | ||
| ChangeLog | ||
| compile | ||
| config-ml.in | ||
| config.guess | ||
| config.rpath | ||
| config.sub | ||
| configure | ||
| configure.ac | ||
| COPYING | ||
| COPYING3 | ||
| COPYING3.LIB | ||
| COPYING.LIB | ||
| COPYING.LIBGLOSS | ||
| COPYING.NEWLIB | ||
| depcomp | ||
| djunpack.bat | ||
| install-sh | ||
| libtool.m4 | ||
| lt~obsolete.m4 | ||
| ltgcc.m4 | ||
| ltmain.sh | ||
| ltoptions.m4 | ||
| ltsugar.m4 | ||
| ltversion.m4 | ||
| MAINTAINERS | ||
| Makefile.def | ||
| Makefile.in | ||
| Makefile.tpl | ||
| makefile.vms | ||
| missing | ||
| mkdep | ||
| mkinstalldirs | ||
| move-if-change | ||
| README | ||
| README-maintainer-mode | ||
| setup.com | ||
| src-release | ||
| symlink-tree | ||
| ylwrap | ||
README for GNU development tools This directory contains various GNU compilers, assemblers, linkers, debuggers, etc., plus their support routines, definitions, and documentation. If you are receiving this as part of a GDB release, see the file gdb/README. If with a binutils release, see binutils/README; if with a libg++ release, see libg++/README, etc. That'll give you info about this package -- supported targets, how to use it, how to report bugs, etc. It is now possible to automatically configure and build a variety of tools with one command. To build all of the tools contained herein, run the ``configure'' script here, e.g.: ./configure make To install them (by default in /usr/local/bin, /usr/local/lib, etc), then do: make install (If the configure script can't determine your type of computer, give it the name as an argument, for instance ``./configure sun4''. You can use the script ``config.sub'' to test whether a name is recognized; if it is, config.sub translates it to a triplet specifying CPU, vendor, and OS.) If you have more than one compiler on your system, it is often best to explicitly set CC in the environment before running configure, and to also set CC when running make. For example (assuming sh/bash/ksh): CC=gcc ./configure make A similar example using csh: setenv CC gcc ./configure make Much of the code and documentation enclosed is copyright by the Free Software Foundation, Inc. See the file COPYING or COPYING.LIB in the various directories, for a description of the GNU General Public License terms under which you can copy the files. REPORTING BUGS: Again, see gdb/README, binutils/README, etc., for info on where and how to report problems.