RFA: infrun.c: mourn instead of kill after TARGET_WAITKIND_SIGNALLED

[Nick Duffek <nsd at cygnus dot com>]

The appended patch calls target_mourn_inferior() instead of target_kill()
in response to TARGET_WAITKIND_SIGNALLED in handle_inferior_event().

This comment precedes the target_kill():

  /* 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.  */

According to target.h, TARGET_WAITKIND_SIGNALLED does indeed mean that the
program has terminated, and all current uses of TARGET_WAITKIND_SIGNALLED
seem to honor that meaning.  Here's where it gets used:

  in target.c:store_waitstatus() when inferior status is !WIFEXITED() &&
    !WIFSTOPPED()
  in gnu-nat.c:inf_task_died_status() when a task has died
  in go32_wait() #if __DJGPP_MINOR__ < 3; I assume this works around
    a lack in older djgpp implementations
  when child goes missing (pid == -1) in:
    linux-thread.c:linuxthreads_wait()
    inftarg.c:child_wait()
    lynx-nat.c:child_wait()
    symm-nat.c:child_wait()
  in lynx-nat.c:child_wait() when defined(SPARC) and inferior status is
    !WIFEXITED() && !WIFSTOPPED()
  in remote-mips.c:mips_wait() when the MIPS protocol returns a value that
    I assume is equivalent to WIFSIGNALED()
  in remote-sim.c:gdbsim_wait() when sim_stop_reason() returns sim_signalled,
    which means that the child has been terminated by a signal
  in remote.c:remote_wait() and remote.c:remote_async_wait() when a packet
    has type 'X', which I assume means the child has terminated due to a
    signal
  in v850ice.c:v850ice_wait() when ExeAppReq() returns ICE_Exception (seems
    to mean segv) or ICE_Terminated

On procfs-based systems, the patch prevents spurious errors like the
following, which GDB prints in response to "continue" after the inferior has
gotten a fatal signal:

   procfs: unconditionally_kill, proc_kill line 4452, /proc/02206: No such file or directory.

On UnixWare, the patch fixes a bug in which "run" and "quit" stop working
after a threaded inferior has gotten a fatal signal.

The patch should make the following code in remote.c and ocd.c unnecessary:

  /* For some mysterious reason, wait_for_inferior calls kill instead of
     mourn after it gets TARGET_WAITKIND_SIGNALLED.  Work around it.  */
  if (kill_kludge)
    {
      kill_kludge = 0;
      target_mourn_inferior ();
      return;
    }

No regressions are evident on i686-pc-linux-gnu or sparc-sun-solaris2.5.1,
and the patch fixes an unexpected failure on the latter.

Okay to commit?

Nick Duffek
nsd@cygnus.com

[patch follows]

Index: infrun.c
===================================================================
RCS file: /cvs/src/src/gdb/infrun.c,v
retrieving revision 1.5
diff -u -r1.5 infrun.c
--- infrun.c	2000/03/28 22:30:19	1.5
+++ infrun.c	2000/04/02 19:21:49
@@ -1554,13 +1554,7 @@
 	stop_print_frame = 0;
 	stop_signal = ecs->ws.value.sig;
 	target_terminal_ours ();	/* Must do this before mourn anyway */
-
-	/* 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 */
+	target_mourn_inferior ();
 
 	print_stop_reason (SIGNAL_EXITED, stop_signal);
 	singlestep_breakpoints_inserted_p = 0;	/*SOFTWARE_SINGLE_STEP_P */