+ resume (0, TARGET_SIGNAL_0);
+ goto wfi_continue;
+
+ case TARGET_WAITKIND_SPURIOUS:
+ resume (0, TARGET_SIGNAL_0);
+ goto wfi_continue;
+
+ case TARGET_WAITKIND_EXITED:
+ target_terminal_ours (); /* Must do this before mourn anyway */
+ annotate_exited (ecs->ws.value.integer);
+ if (ecs->ws.value.integer)
+ printf_filtered ("\nProgram exited with code 0%o.\n",
+ (unsigned int) ecs->ws.value.integer);
+ else
+ printf_filtered ("\nProgram exited normally.\n");
+
+ /* Record the exit code in the convenience variable $_exitcode, so
+ that the user can inspect this again later. */
+ set_internalvar (lookup_internalvar ("_exitcode"),
+ value_from_longest (builtin_type_int,
+ (LONGEST) ecs->ws.value.integer));
+ gdb_flush (gdb_stdout);
+ target_mourn_inferior ();
+ singlestep_breakpoints_inserted_p = 0; /*SOFTWARE_SINGLE_STEP_P */
+ stop_print_frame = 0;
+ goto stop_stepping;
+
+ case TARGET_WAITKIND_SIGNALLED:
+ stop_print_frame = 0;
+ stop_signal = ecs->ws.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 = ecs->ws.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 == ecs->pid)
+ {
+ pending_follow.fork_event.saw_parent_fork = 1;
+ pending_follow.fork_event.parent_pid = ecs->pid;
+ pending_follow.fork_event.child_pid = ecs->ws.value.related_pid;
+ goto wfi_continue;
+ }
+ else
+ {
+ pending_follow.fork_event.saw_child_fork = 1;
+ pending_follow.fork_event.child_pid = ecs->pid;
+ pending_follow.fork_event.parent_pid = ecs->ws.value.related_pid;
+ }
+
+ stop_pc = read_pc_pid (ecs->pid);
+ ecs->saved_inferior_pid = inferior_pid;
+ inferior_pid = ecs->pid;
+ stop_bpstat = bpstat_stop_status
+ (&stop_pc,
+ (DECR_PC_AFTER_BREAK ?
+ (prev_pc != stop_pc - DECR_PC_AFTER_BREAK
+ && currently_stepping (ecs))
+ : 0)
+ );
+ ecs->random_signal = !bpstat_explains_signal (stop_bpstat);
+ inferior_pid = ecs->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 = 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 (ecs->pid == inferior_pid)
+ {
+ pending_follow.fork_event.saw_parent_fork = 1;
+ pending_follow.fork_event.parent_pid = ecs->pid;
+ 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 = ecs->pid;
+ pending_follow.fork_event.parent_pid = ecs->ws.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 (ecs->pid, 0, TARGET_SIGNAL_0);
+ goto wfi_continue;
+ }
+ }
+
+ stop_pc = read_pc ();
+ stop_bpstat = bpstat_stop_status
+ (&stop_pc,
+ (DECR_PC_AFTER_BREAK ?
+ (prev_pc != stop_pc - DECR_PC_AFTER_BREAK
+ && currently_stepping (ecs))
+ : 0)
+ );
+ 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->pid, 0, TARGET_SIGNAL_0);
+ goto wfi_continue;
+ }
+ 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_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 (ecs->pid, 1, TARGET_SIGNAL_0);
+ /* We expect the parent vfork event to be available now. */
+ goto wfi_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 (ecs->pid);
+ ecs->saved_inferior_pid = inferior_pid;
+ inferior_pid = ecs->pid;
+ stop_bpstat = bpstat_stop_status
+ (&stop_pc,
+ (DECR_PC_AFTER_BREAK ?
+ (prev_pc != stop_pc - DECR_PC_AFTER_BREAK
+ && currently_stepping (ecs))
+ : 0)
+ );
+ ecs->random_signal = !bpstat_explains_signal (stop_bpstat);
+ inferior_pid = ecs->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);
+ goto wfi_continue;
+
+ /* Before examining the threads further, step this thread to
+ get it entirely out of the syscall. (We get notice of the
+ event when the thread is just on the verge of exiting a
+ syscall. Stepping one instruction seems to get it back
+ into user code.)
+
+ Note that although the logical place to reenable h/w watches
+ is here, we cannot. We cannot reenable them before stepping
+ the thread (this causes the next wait on the thread to hang).
+
+ Nor can we enable them after stepping until we've done a wait.
+ Thus, we simply set the flag ecs->enable_hw_watchpoints_after_wait
+ here, which will be serviced immediately after the target
+ is waited on. */
+ case TARGET_WAITKIND_SYSCALL_RETURN:
+ target_resume (ecs->pid, 1, TARGET_SIGNAL_0);
+
+ if (number_of_threads_in_syscalls > 0)
+ {
+ number_of_threads_in_syscalls--;
+ ecs->enable_hw_watchpoints_after_wait =
+ (number_of_threads_in_syscalls == 0);
+ }
+ goto wfi_continue;
+
+ case TARGET_WAITKIND_STOPPED:
+ stop_signal = ecs->ws.value.sig;
+ break;
+ }
+
+ /* We may want to consider not doing a resume here in order to give
+ the user a chance to play with the new thread. It might be good
+ to make that a user-settable option. */
+
+ /* At this point, all threads are stopped (happens automatically in
+ either the OS or the native code). Therefore we need to continue
+ all threads in order to make progress. */
+ if (ecs->new_thread_event)
+ {
+ target_resume (-1, 0, TARGET_SIGNAL_0);
+ goto wfi_continue;
+ }
+
+ stop_pc = read_pc_pid (ecs->pid);
+
+ /* See if a thread hit a thread-specific breakpoint that was meant for
+ another thread. If so, then step that thread past the breakpoint,
+ and continue it. */
+
+ if (stop_signal == TARGET_SIGNAL_TRAP)
+ {
+ if (SOFTWARE_SINGLE_STEP_P && singlestep_breakpoints_inserted_p)
+ ecs->random_signal = 0;
+ else if (breakpoints_inserted
+ && breakpoint_here_p (stop_pc - DECR_PC_AFTER_BREAK))
+ {
+ ecs->random_signal = 0;
+ if (!breakpoint_thread_match (stop_pc - DECR_PC_AFTER_BREAK,
+ ecs->pid))
+ {
+ int remove_status;
+
+ /* Saw a breakpoint, but it was hit by the wrong thread.
+ Just continue. */
+ write_pc_pid (stop_pc - DECR_PC_AFTER_BREAK, ecs->pid);
+
+ remove_status = remove_breakpoints ();
+ /* Did we fail to remove breakpoints? If so, try
+ to set the PC past the bp. (There's at least
+ one situation in which we can fail to remove
+ the bp's: On HP-UX's that use ttrace, we can't
+ change the address space of a vforking child
+ process until the child exits (well, okay, not
+ then either :-) or execs. */
+ if (remove_status != 0)
+ {
+ write_pc_pid (stop_pc - DECR_PC_AFTER_BREAK + 4, ecs->pid);
+ }
+ else
+ { /* Single step */
+ target_resume (ecs->pid, 1, TARGET_SIGNAL_0);
+ /* FIXME: What if a signal arrives instead of the
+ single-step happening? */
+
+ ecs->waiton_pid = ecs->pid;
+ ecs->wp = &(ecs->ws);
+ ecs->infwait_state = infwait_thread_hop_state;
+ goto wfi_continue;
+ }
+
+ /* We need to restart all the threads now,
+ * unles we're running in scheduler-locked mode.
+ * FIXME: shouldn't we look at currently_stepping ()?
+ */
+ if (scheduler_mode == schedlock_on)
+ target_resume (ecs->pid, 0, TARGET_SIGNAL_0);
+ else
+ target_resume (-1, 0, TARGET_SIGNAL_0);
+ goto wfi_continue;
+ }
+ else
+ {
+ /* This breakpoint matches--either it is the right
+ thread or it's a generic breakpoint for all threads.
+ Remember that we'll need to step just _this_ thread
+ on any following user continuation! */
+ thread_step_needed = 1;
+ }
+ }
+ }
+ else
+ ecs->random_signal = 1;
+
+ /* See if something interesting happened to the non-current thread. If
+ so, then switch to that thread, and eventually give control back to
+ the user.
+
+ Note that if there's any kind of pending follow (i.e., of a fork,
+ vfork or exec), we don't want to do this now. Rather, we'll let
+ the next resume handle it. */
+ if ((ecs->pid != inferior_pid) &&
+ (pending_follow.kind == TARGET_WAITKIND_SPURIOUS))
+ {
+ int printed = 0;
+
+ /* If it's a random signal for a non-current thread, notify user
+ if he's expressed an interest. */
+ if (ecs->random_signal
+ && signal_print[stop_signal])
+ {
+/* ??rehrauer: I don't understand the rationale for this code. If the
+ inferior will stop as a result of this signal, then the act of handling
+ the stop ought to print a message that's couches the stoppage in user
+ terms, e.g., "Stopped for breakpoint/watchpoint". If the inferior
+ won't stop as a result of the signal -- i.e., if the signal is merely
+ a side-effect of something GDB's doing "under the covers" for the
+ user, such as stepping threads over a breakpoint they shouldn't stop
+ for -- then the message seems to be a serious annoyance at best.
+
+ For now, remove the message altogether. */
+#if 0
+ printed = 1;
+ target_terminal_ours_for_output ();
+ printf_filtered ("\nProgram received signal %s, %s.\n",
+ target_signal_to_name (stop_signal),
+ target_signal_to_string (stop_signal));
+ gdb_flush (gdb_stdout);