On Friday 12 December 2008 01:11:13, Pedro Alves wrote:
> To fix this, we either set inferior_ptid to null_ptid before deleting the
> inferior when we want to prevent this, or, we defer deleting the inferior to
> generic_mourn_inferior, which does just that.  I've done the latter.

Next in queue, make the extended-remote version of mourning always
call generic_mourn_inferior, to always get rid of the current inferior,
even if there are more inferiors to debug.  This only became possible
since the change to make handle_inferior_event switch inferior_ptid to the
event ptid on a process exit (we were also discarding leftover
unprocessed events from the wrong inferior before that change, just a
bit above the generic_mourn_inferior call I'm moving).

Tested against an x86_64-linux-gnu gdbserver.  Checked in.


The next issue is that extended_remote_mourn is handling the switching
to another process itself, which was an idea borrowed from the linux
multi-fork support.  This is problematic for a few reasons, and would be
best done in common code.  More on that soon.

-- 
Pedro Alves