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

[Pedro Alves <pedro at codesourcery dot com>]

On Tuesday 17 February 2009 16:19:55, Marc Khouzam wrote:

> > 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.
> 
> Your patches does not do this yet, right?

Right.

> > 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!).
> 
> I don't think you explicitely said it (or maybe I've read too
> many emails today), but I believe you are suggesting that GDB
> be allowed to be in a state where no thread is selected and
> this state should be handled properly when receiving commands.

Yes.

> 
> I didn't quite understand what responsibility falls on the 
> frontend with this suggestion.  

E.g., I'd like to understand what does eclipse do when it
receives a "=thread-group-exited" notification, and the thread
that eclipse had selected disappeared.  Was it expecting that
GDB changed to another random thread (and emit a =thread-selected
notification), or was it supposed to select another thread itself?
Or, does it also have a state of "no thread selected" in the UI?

> 
> I wanted to try to patch to see what you meant more clearly.
> However, I think this patch applies to HEAD but HEAD does
> not work with my stub yet (the -list-thread-groups --available
> problem).

Oh, bummer.  I thought you'd have some way to manually specify which
process to attach to without going through that listing.

-- 
Pedro Alves