- case TARGET_WAITKIND_SIGNALLED:
- stop_print_frame = 0;
- stop_signal = w.value.sig;
- target_terminal_ours (); /* Must do this before mourn anyway */
- annotate_signalled ();
-
- /* This looks pretty bogus to me. Doesn't TARGET_WAITKIND_SIGNALLED
- mean it is already dead? This has been here since GDB 2.8, so
- perhaps it means rms didn't understand unix waitstatuses?
- For the moment I'm just kludging around this in remote.c
- rather than trying to change it here --kingdon, 5 Dec 1994. */
- target_kill (); /* kill mourns as well */
-
- printf_filtered ("\nProgram terminated with signal ");
- annotate_signal_name ();
- printf_filtered ("%s", target_signal_to_name (stop_signal));
- annotate_signal_name_end ();
- printf_filtered (", ");
- annotate_signal_string ();
- printf_filtered ("%s", target_signal_to_string (stop_signal));
- annotate_signal_string_end ();
- printf_filtered (".\n");
-
- printf_filtered ("The program no longer exists.\n");
- gdb_flush (gdb_stdout);
- singlestep_breakpoints_inserted_p = 0; /*SOFTWARE_SINGLE_STEP_P*/
- goto stop_stepping;
-
- /* The following are the only cases in which we keep going;
- the above cases end in a continue or goto. */
- case TARGET_WAITKIND_FORKED:
- stop_signal = TARGET_SIGNAL_TRAP;
- pending_follow.kind = w.kind;
-
- /* Ignore fork events reported for the parent; we're only
- interested in reacting to forks of the child. Note that
- we expect the child's fork event to be available if we
- waited for it now. */
- if (inferior_pid == pid)
- {
- pending_follow.fork_event.saw_parent_fork = 1;
- pending_follow.fork_event.parent_pid = pid;
- pending_follow.fork_event.child_pid = w.value.related_pid;
- continue;
- }
- else
- {
- pending_follow.fork_event.saw_child_fork = 1;
- pending_follow.fork_event.child_pid = pid;
- pending_follow.fork_event.parent_pid = w.value.related_pid;
- }
-
- stop_pc = read_pc_pid (pid);
- saved_inferior_pid = inferior_pid;
- inferior_pid = pid;
- stop_bpstat = bpstat_stop_status
- (&stop_pc,
-#if DECR_PC_AFTER_BREAK
- (prev_pc != stop_pc - DECR_PC_AFTER_BREAK
- && CURRENTLY_STEPPING ())
-#else /* DECR_PC_AFTER_BREAK zero */
- 0
-#endif /* DECR_PC_AFTER_BREAK zero */
- );
- random_signal = ! bpstat_explains_signal (stop_bpstat);
- inferior_pid = saved_inferior_pid;
- goto process_event_stop_test;
-
- /* If this a platform which doesn't allow a debugger to touch a
- vfork'd inferior until after it exec's, then we'd best keep
- our fingers entirely off the inferior, other than continuing
- it. This has the unfortunate side-effect that catchpoints
- of vforks will be ignored. But since the platform doesn't
- allow the inferior be touched at vfork time, there's really
- little choice. */
- case TARGET_WAITKIND_VFORKED:
- stop_signal = TARGET_SIGNAL_TRAP;
- pending_follow.kind = w.kind;
-
- /* Is this a vfork of the parent? If so, then give any
- vfork catchpoints a chance to trigger now. (It's
- dangerous to do so if the child canot be touched until
- it execs, and the child has not yet exec'd. We probably
- should warn the user to that effect when the catchpoint
- triggers...) */
- if (pid == inferior_pid)
- {
- pending_follow.fork_event.saw_parent_fork = 1;
- pending_follow.fork_event.parent_pid = pid;
- pending_follow.fork_event.child_pid = w.value.related_pid;
- }
-
- /* If we've seen the child's vfork event but cannot really touch
- the child until it execs, then we must continue the child now.
- Else, give any vfork catchpoints a chance to trigger now. */
- else
- {
- pending_follow.fork_event.saw_child_fork = 1;
- pending_follow.fork_event.child_pid = pid;
- pending_follow.fork_event.parent_pid = w.value.related_pid;
- target_post_startup_inferior (pending_follow.fork_event.child_pid);
- follow_vfork_when_exec = ! target_can_follow_vfork_prior_to_exec ();
- if (follow_vfork_when_exec)
- {
- target_resume (pid, 0, TARGET_SIGNAL_0);
- continue;
- }
- }
-
- stop_pc = read_pc ();
- stop_bpstat = bpstat_stop_status
- (&stop_pc,
-#if DECR_PC_AFTER_BREAK
- (prev_pc != stop_pc - DECR_PC_AFTER_BREAK
- && CURRENTLY_STEPPING ())
-#else /* DECR_PC_AFTER_BREAK zero */
- 0
-#endif /* DECR_PC_AFTER_BREAK zero */
- );
- random_signal = ! bpstat_explains_signal (stop_bpstat);
- goto process_event_stop_test;
-
- case TARGET_WAITKIND_EXECD:
- stop_signal = TARGET_SIGNAL_TRAP;
-
- /* Is this a target which reports multiple exec events per actual
- call to exec()? (HP-UX using ptrace does, for example.) If so,
- ignore all but the last one. Just resume the exec'r, and wait
- for the next exec event. */
- if (inferior_ignoring_leading_exec_events)
- {
- inferior_ignoring_leading_exec_events--;
- if (pending_follow.kind == TARGET_WAITKIND_VFORKED)
- ENSURE_VFORKING_PARENT_REMAINS_STOPPED(pending_follow.fork_event.parent_pid);
- target_resume (pid, 0, TARGET_SIGNAL_0);
- continue;
- }
- inferior_ignoring_leading_exec_events =
- target_reported_exec_events_per_exec_call () - 1;
-
- pending_follow.execd_pathname = savestring (w.value.execd_pathname,
- strlen (w.value.execd_pathname));
-
- /* Did inferior_pid exec, or did a (possibly not-yet-followed)
- child of a vfork exec?
-
- ??rehrauer: This is unabashedly an HP-UX specific thing. On
- HP-UX, events associated with a vforking inferior come in
- threes: a vfork event for the child (always first), followed
- a vfork event for the parent and an exec event for the child.
- The latter two can come in either order.
-
- If we get the parent vfork event first, life's good: We follow
- either the parent or child, and then the child's exec event is
- a "don't care".
-
- But if we get the child's exec event first, then we delay
- responding to it until we handle the parent's vfork. Because,
- otherwise we can't satisfy a "catch vfork". */
- if (pending_follow.kind == TARGET_WAITKIND_VFORKED)
- {
- pending_follow.fork_event.saw_child_exec = 1;
-
- /* On some targets, the child must be resumed before
- the parent vfork event is delivered. A single-step
- suffices. */
- if (RESUME_EXECD_VFORKING_CHILD_TO_GET_PARENT_VFORK())
- target_resume (pid, 1, TARGET_SIGNAL_0);
- /* We expect the parent vfork event to be available now. */
- continue;
- }
-
- /* This causes the eventpoints and symbol table to be reset. Must
- do this now, before trying to determine whether to stop. */
- follow_exec (inferior_pid, pending_follow.execd_pathname);
- free (pending_follow.execd_pathname);
-
- stop_pc = read_pc_pid (pid);
- saved_inferior_pid = inferior_pid;
- inferior_pid = pid;
- stop_bpstat = bpstat_stop_status
- (&stop_pc,
-#if DECR_PC_AFTER_BREAK
- (prev_pc != stop_pc - DECR_PC_AFTER_BREAK
- && CURRENTLY_STEPPING ())
-#else /* DECR_PC_AFTER_BREAK zero */
- 0
-#endif /* DECR_PC_AFTER_BREAK zero */
- );
- random_signal = ! bpstat_explains_signal (stop_bpstat);
- inferior_pid = saved_inferior_pid;
- goto process_event_stop_test;
-
- /* These syscall events are returned on HP-UX, as part of its
- implementation of page-protection-based "hardware" watchpoints.
- HP-UX has unfortunate interactions between page-protections and
- some system calls. Our solution is to disable hardware watches
- when a system call is entered, and reenable them when the syscall
- completes. The downside of this is that we may miss the precise
- point at which a watched piece of memory is modified. "Oh well."
-
- Note that we may have multiple threads running, which may each
- enter syscalls at roughly the same time. Since we don't have a
- good notion currently of whether a watched piece of memory is
- thread-private, we'd best not have any page-protections active
- when any thread is in a syscall. Thus, we only want to reenable
- hardware watches when no threads are in a syscall.
-
- Also, be careful not to try to gather much state about a thread
- that's in a syscall. It's frequently a losing proposition. */
- case TARGET_WAITKIND_SYSCALL_ENTRY:
- number_of_threads_in_syscalls++;
- if (number_of_threads_in_syscalls == 1)
- {
- TARGET_DISABLE_HW_WATCHPOINTS(inferior_pid);
- }
- resume (0, TARGET_SIGNAL_0);
- continue;
-
- /* Before examining the threads further, step this thread to
+ stop_pc = read_pc_pid (ecs->ptid);
+ ecs->saved_inferior_ptid = inferior_ptid;
+ inferior_ptid = ecs->ptid;
+ /* The second argument of bpstat_stop_status is meant to help
+ distinguish between a breakpoint trap and a singlestep trap.
+ This is only important on targets where DECR_PC_AFTER_BREAK
+ is non-zero. The prev_pc test is meant to distinguish between
+ singlestepping a trap instruction, and singlestepping thru a
+ jump to the instruction following a trap instruction. */
+
+ stop_bpstat = bpstat_stop_status (&stop_pc,
+ currently_stepping (ecs) &&
+ prev_pc !=
+ stop_pc - DECR_PC_AFTER_BREAK);
+ ecs->random_signal = !bpstat_explains_signal (stop_bpstat);
+ inferior_ptid = ecs->saved_inferior_ptid;
+ goto process_event_stop_test;
+
+ /* If this a platform which doesn't allow a debugger to touch a
+ vfork'd inferior until after it exec's, then we'd best keep
+ our fingers entirely off the inferior, other than continuing
+ it. This has the unfortunate side-effect that catchpoints
+ of vforks will be ignored. But since the platform doesn't
+ allow the inferior be touched at vfork time, there's really
+ little choice. */
+ case TARGET_WAITKIND_VFORKED:
+ stop_signal = TARGET_SIGNAL_TRAP;
+ pending_follow.kind = ecs->ws.kind;
+
+ /* Is this a vfork of the parent? If so, then give any
+ vfork catchpoints a chance to trigger now. (It's
+ dangerous to do so if the child canot be touched until
+ it execs, and the child has not yet exec'd. We probably
+ should warn the user to that effect when the catchpoint
+ triggers...) */
+ if (ptid_equal (ecs->ptid, inferior_ptid))
+ {
+ pending_follow.fork_event.saw_parent_fork = 1;
+ pending_follow.fork_event.parent_pid = PIDGET (ecs->ptid);
+ pending_follow.fork_event.child_pid = ecs->ws.value.related_pid;
+ }
+
+ /* If we've seen the child's vfork event but cannot really touch
+ the child until it execs, then we must continue the child now.
+ Else, give any vfork catchpoints a chance to trigger now. */
+ else
+ {
+ pending_follow.fork_event.saw_child_fork = 1;
+ pending_follow.fork_event.child_pid = PIDGET (ecs->ptid);
+ pending_follow.fork_event.parent_pid = ecs->ws.value.related_pid;
+ target_post_startup_inferior (
+ pid_to_ptid (pending_follow.fork_event.child_pid));
+ follow_vfork_when_exec = !target_can_follow_vfork_prior_to_exec ();
+ if (follow_vfork_when_exec)
+ {
+ target_resume (ecs->ptid, 0, TARGET_SIGNAL_0);
+ prepare_to_wait (ecs);
+ return;
+ }
+ }
+
+ stop_pc = read_pc ();
+ /* The second argument of bpstat_stop_status is meant to help
+ distinguish between a breakpoint trap and a singlestep trap.
+ This is only important on targets where DECR_PC_AFTER_BREAK
+ is non-zero. The prev_pc test is meant to distinguish between
+ singlestepping a trap instruction, and singlestepping thru a
+ jump to the instruction following a trap instruction. */
+
+ stop_bpstat = bpstat_stop_status (&stop_pc,
+ currently_stepping (ecs) &&
+ prev_pc !=
+ stop_pc - DECR_PC_AFTER_BREAK);
+ ecs->random_signal = !bpstat_explains_signal (stop_bpstat);
+ goto process_event_stop_test;
+
+ case TARGET_WAITKIND_EXECD:
+ stop_signal = TARGET_SIGNAL_TRAP;
+
+ /* Is this a target which reports multiple exec events per actual
+ call to exec()? (HP-UX using ptrace does, for example.) If so,
+ ignore all but the last one. Just resume the exec'r, and wait
+ for the next exec event. */
+ if (inferior_ignoring_leading_exec_events)
+ {
+ inferior_ignoring_leading_exec_events--;
+ if (pending_follow.kind == TARGET_WAITKIND_VFORKED)
+ ENSURE_VFORKING_PARENT_REMAINS_STOPPED (pending_follow.fork_event.parent_pid);
+ target_resume (ecs->ptid, 0, TARGET_SIGNAL_0);
+ prepare_to_wait (ecs);
+ return;
+ }
+ inferior_ignoring_leading_exec_events =
+ target_reported_exec_events_per_exec_call () - 1;
+
+ pending_follow.execd_pathname =
+ savestring (ecs->ws.value.execd_pathname,
+ strlen (ecs->ws.value.execd_pathname));
+
+ /* Did inferior_ptid exec, or did a (possibly not-yet-followed)
+ child of a vfork exec?
+
+ ??rehrauer: This is unabashedly an HP-UX specific thing. On
+ HP-UX, events associated with a vforking inferior come in
+ threes: a vfork event for the child (always first), followed
+ a vfork event for the parent and an exec event for the child.
+ The latter two can come in either order.
+
+ If we get the parent vfork event first, life's good: We follow
+ either the parent or child, and then the child's exec event is
+ a "don't care".
+
+ But if we get the child's exec event first, then we delay
+ responding to it until we handle the parent's vfork. Because,
+ otherwise we can't satisfy a "catch vfork". */
+ if (pending_follow.kind == TARGET_WAITKIND_VFORKED)
+ {
+ pending_follow.fork_event.saw_child_exec = 1;
+
+ /* On some targets, the child must be resumed before
+ the parent vfork event is delivered. A single-step
+ suffices. */
+ if (RESUME_EXECD_VFORKING_CHILD_TO_GET_PARENT_VFORK ())
+ target_resume (ecs->ptid, 1, TARGET_SIGNAL_0);
+ /* We expect the parent vfork event to be available now. */
+ prepare_to_wait (ecs);
+ return;
+ }
+
+ /* This causes the eventpoints and symbol table to be reset. Must
+ do this now, before trying to determine whether to stop. */
+ follow_exec (PIDGET (inferior_ptid), pending_follow.execd_pathname);
+ xfree (pending_follow.execd_pathname);
+
+ stop_pc = read_pc_pid (ecs->ptid);
+ ecs->saved_inferior_ptid = inferior_ptid;
+ inferior_ptid = ecs->ptid;
+ /* The second argument of bpstat_stop_status is meant to help
+ distinguish between a breakpoint trap and a singlestep trap.
+ This is only important on targets where DECR_PC_AFTER_BREAK
+ is non-zero. The prev_pc test is meant to distinguish between
+ singlestepping a trap instruction, and singlestepping thru a
+ jump to the instruction following a trap instruction. */
+
+ stop_bpstat = bpstat_stop_status (&stop_pc,
+ currently_stepping (ecs) &&
+ prev_pc !=
+ stop_pc - DECR_PC_AFTER_BREAK);
+ ecs->random_signal = !bpstat_explains_signal (stop_bpstat);
+ inferior_ptid = ecs->saved_inferior_ptid;
+ goto process_event_stop_test;
+
+ /* These syscall events are returned on HP-UX, as part of its
+ implementation of page-protection-based "hardware" watchpoints.
+ HP-UX has unfortunate interactions between page-protections and
+ some system calls. Our solution is to disable hardware watches
+ when a system call is entered, and reenable them when the syscall
+ completes. The downside of this is that we may miss the precise
+ point at which a watched piece of memory is modified. "Oh well."
+
+ Note that we may have multiple threads running, which may each
+ enter syscalls at roughly the same time. Since we don't have a
+ good notion currently of whether a watched piece of memory is
+ thread-private, we'd best not have any page-protections active
+ when any thread is in a syscall. Thus, we only want to reenable
+ hardware watches when no threads are in a syscall.
+
+ Also, be careful not to try to gather much state about a thread
+ that's in a syscall. It's frequently a losing proposition. */
+ case TARGET_WAITKIND_SYSCALL_ENTRY:
+ number_of_threads_in_syscalls++;
+ if (number_of_threads_in_syscalls == 1)
+ {
+ TARGET_DISABLE_HW_WATCHPOINTS (PIDGET (inferior_ptid));
+ }
+ resume (0, TARGET_SIGNAL_0);
+ prepare_to_wait (ecs);
+ return;
+
+ /* Before examining the threads further, step this thread to