Hi guys,

Can I take it that there are no objections to the target side bits?

Mark, adding you to CC in case you want to comment on the inf-ptrace bit?

I'd like to check this in so I can move on with some other
remote.c cleanups dependent on this.  I'll do any extra fixing if
it turns out necessary.

On Sunday 07 December 2008 20:16:09, Pedro Alves wrote:
> 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