aboutsummaryrefslogtreecommitdiff
path: root/gdb/dwarf2read.c
diff options
context:
space:
mode:
authorDon Breazeal <donb@codesourcery.com>2015-05-12 09:52:46 -0700
committerDon Breazeal <donb@codesourcery.com>2015-05-12 09:52:46 -0700
commitcbb8991cabdd85b7828f59c92f754c5a2101b0b6 (patch)
treeb6c32500084315697e5b2d730be9f5162a22231a /gdb/dwarf2read.c
parentc269dbdb603216de2be52f07f26e65ead7e11c7b (diff)
downloadgdb-cbb8991cabdd85b7828f59c92f754c5a2101b0b6.zip
gdb-cbb8991cabdd85b7828f59c92f754c5a2101b0b6.tar.gz
gdb-cbb8991cabdd85b7828f59c92f754c5a2101b0b6.tar.bz2
Extended-remote fork catch
This patch implements catchpoints for fork events on extended-remote Linux targets. Implementation appeared to be straightforward, requiring four new functions in remote.c to implement insert/remove of fork/vfork catchpoints. These functions are essentially stubs that just return 0 ('success') if the required features are enabled. If the fork events are being reported, then catchpoints are set and hit. However, there are some extra issues that arise with catchpoints. 1) Thread creation reporting -- fork catchpoints are hit before the follow_fork has been completed. When stopped at a fork catchpoint in the native implementation, the new process is not 'reported' until after the follow is done. It doesn't show up in the inferiors list or the threads list. However, in the gdbserver case, an 'info threads' while stopped at a fork catchpoint will retrieve the new thread info from the target and add it to GDB's data structures, prior to the follow operations. Because of this premature report, things on the GDB side eventually get very confused. So in remote.c:remote_update_thread_list, we check to see if there are any pending fork parent threads. If there are we remove the related fork child thread from the thread list sent by the target. 2) Kill process before fork is followed -- on the native side in linux-nat.c:linux_nat_kill, there is some code to handle the case where a fork has occurred but follow_fork hasn't been called yet. It does this by using the last status to determine if a follow is pending, and if it is, to kill the child task. The use of last_status is fragile in situations like non-stop mode where other events may have occurred after the fork event. This patch identifies a fork parent in remote.c:extended_remote_kill in a way similar to that used in thread creation reporting above. If one is found, it kills the new child as well. Tested on x64 Ubuntu Lucid, native, remote, extended-remote. Tested the case of killing the forking process before the fork has been followed manually. gdb/ChangeLog: * remote.c (remote_insert_fork_catchpoint): New function. (remote_remove_fork_catchpoint): New function. (remote_insert_vfork_catchpoint): New function. (remote_remove_vfork_catchpoint): New function. (pending_fork_parent_callback): New function. (remove_new_fork_child): New function. (remote_update_thread_list): Call remote_notif_get_pending_events and remove_new_fork_child. (extended_remote_kill): Kill fork child when killing the parent before follow_fork completes. (init_extended_remote_ops): Initialize target vector with new fork catchpoint functions.
Diffstat (limited to 'gdb/dwarf2read.c')
0 files changed, 0 insertions, 0 deletions