Here's a piece I mentioned a bit earlier today.  In multi-process,
we may be calling target_mourn_inferior on the wrong inferior, if the
inferior that exited happens to *not* be the current inferior the
user has selected.  The obvious fix is to switch inferior_ptid
to the ecs->ptid.

But, there are a few targets that return invalid ptids
on a TARGET_WAITKIND_EXIT or TARGET_WAITKIND_SIGNALLED.  Even if
they don't support multi-process, that means that later on,
when target_mourn_inferior->generic_mourn_inferior is called,
we would leave the dead inferior still listed (and if we have breakpoint
locations per-inferior, as in the multiprocess branch, we will delete
the breakpoint locations of the wrong inferior).

The linux-thread-db.c has no good reason to be filtering the ptid
the beneath target returns, so that's easy to fix, just return
that the beneath layer returned.

The other targets I'm adjusting, are doing this:

  if (pid == -1)
    {
      warning (_("Child process unexpectedly missing: %s"),
	       safe_strerror (save_errno));

      /* Claim it exited with unknown signal.  */
      ourstatus->kind = TARGET_WAITKIND_SIGNALLED;
      ourstatus->value.sig = TARGET_SIGNAL_UNKNOWN;
      return minus_one_ptid;
    }

I'm not 100% sure what this catches, and, if this can really happen.
A 'kill -9' perhaps?  I've changed them to return inferior_ptid
instead, which should still be OK, unless their target_mourn_inferior
implementation could hang in that case --- I think not though.  If we find
that this is a problem, then we'll need a new TARGET_WAITKIND_DISAPPEARED
and perhaps a corresponding new target_ops method to handle it (or
just call generic_mourn_inferior) ...

Comments?

(I think that with further cleanups, we'll be switching
inferior_ptid unconditionaly to the event ptid in all-stop as well...)

-- 
Pedro Alves