Re: Process exit in multi-process, and gdb's selected thread.

[Tom Tromey <tromey at redhat dot com>]

>>>>> "Pedro" == Pedro Alves <pedro@codesourcery.com> writes:

I meant to reply to this earlier...

Pedro> What would you think if GDB could get into this state,
Pedro> after a process exit? :
Pedro>  (gdb) info threads
Pedro>    2 Thread 31176.31176  0x00007f0706154796 in ?? ()
[...]

I think it is a reasonable outcome given the model.  If users find it
too confusing, we can try to add some extra output somewhere -- for
instance, when gdb says "The program is not being run.", it could
check for multiple inferiors and print something about how to switch
to another inferior.

I tend to doubt that we will need to do this, though, because I think
this is the most logical way for multi-inferior debugging to work.

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

I agree.

Pedro> What do you think of all this, am I making sense?

Yeah, I think your choices here make sense, particularly not having
gdb switch contexts behind the user's back, and that what you wrote up
is the logical outcome of this decision.

Tom