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

[Pedro Alves <pedro at codesourcery dot com>]

On Tuesday 24 February 2009 19:56:17, Tom Tromey wrote:
> >>>>> "Pedro" == Pedro Alves <pedro@codesourcery.com> writes:
> 
> I meant to reply to this earlier...
> 

Makes two of us now.  :-)

> 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.

Great then.   Since there were no objections to this, and Marc
has been using this patch against his multi-process aware system
for a while now without problems, I checked it in.

-- 
Pedro Alves