Hi!

I've been thinking about issues related to what to do with GDB's
notion of selected thread, if we're debugging more than one process
simultaneously, and the current processes exits.

What would you think if GDB could get into this state,
after a process exit? :

 (gdb) info threads
   2 Thread 31176.31176  0x00007f0706154796 in ?? ()

 No selected thread.  See `help thread'.
 (gdb) info inferiors
   3 31176
 (gdb) c
 Continuing.
 Cannot execute this command without a live selected thread.
 (gdb) detach
 The program is not being run.
 (gdb) kill
 The program is not being run.
 (gdb)   

This would happen, e.g., if the current process (it was some other
pid, not 31176) had exited or was detached from.  Keep in mind that in
non-stop mode, we prefer that GDB doesn't switch threads behind the
user's back while he is typing some command. This way, when the
current thread and inferior no longer exist, GDB switches to a state that
should be safe, and the onus is on the frontend to switch to
whatever thread it wants.

In the past, I had solved this by spreading around some hacks
that tried to detect the current inferior exiting, and switching
to any other random live thread, but, that turned out to be: first,
surprising in non-stop mode, in the case mentioned above; and
second, surprisingly difficult to get right.  I think this usually
means that GDB shouldn't try to be smart (well, or I shouldn't).

I've tried avoiding before getting to a state where GDB has
no thread selected, when there are threads in the thread list.  But,
I don't think we'll be able to avoid it in the long run.  E.g., when
GDB gains ability to load more than on program (exec) at the same time,
(say, "cat", and "grep"), even if "cat" is running already, it will fell
natural to be able to select the "grep" executable as focus, thus,
the selected thread in that case should be "null".   (Also thinking about
the possibility of GDB being able in the future to switch to some form
of post-or-quasi-mortem debugging mode when a process exits, I'd want GDB
to not switch threads to some other process on a process exit.)

A bit related to this, is the hack we have currently that tags a
few commands as being "safe to apply without a valid
selected thread".  This served its purpose when non-stop was first
introduced, but, I think it's time we remove them, and start making
the checks at a lower level.  They are currently done at a too high
level currently, which ends up getting in the way many times.  We need
more finer grained control over which operations can and can't be
applied without a valid thread selected, so we need to push those
checks down, more close to core code, or even to target code.

I'm thinking that we may need to extend the =thread-selected
notification to tell the frontend that there's no thread selected,
and perhaps the -thread-info,current-thread-id, output too.

What do you think of all this, am I making sense?  Or, does it
sound like "let's hope he comes back to senses soon, for he's
not making any"?  :-)

Here's my current patch that implements this, in case you
have a stub around that implements multi-process (Hi Marc!).

-- 
Pedro Alves