Re: Multiprocess MI extensions

[Vladimir Prus <vladimir@codesourcery.com>]

On Tuesday 17 June 2008 22:32:06 Marc Khouzam wrote:
> 
> > > Currently, when the inferior exits, there is an event that 
> > looks like:
> > > *stopped,reason="exited-normally"
> > > or some other variant.
> > > 
> > > I gather this is not a considered option for multi-process?
> > > It probably would have helped with backwards compatibility.
> > 
> > I don't know, honestly. Is extending *stopped with 
> > thread-group field really
> > much better for backward compatibility that new notification?
> 
> I had imagined to make multi-process debugging the only variant, which
> would makes a single-process session actually be a multi-process one
> with a single process (or thread-group).

This is the ultimate goal.

> But what we can do is look for both the new notification for process exit
> and the *stopped one, which ever _one_ we see, will be the trigger.
> So, as long as we get one or the other but not both at the same time,
> it should be fine.

I need to think about this more -- I just don't know what's the right thing here.
 
> On another point for multi-process, I was wondering if there will be a need
> to select a thread-group before issuing commands affecting a entire
> group?  Something similar to what we have with -thread-select.  
> I was thinking that a command affecting a group would apply to the group
> to which the current thread belongs.
> 
> This would allow for any command currently applicable to the single process
> or inferior, to be applied in the same way.  To be honnest, I'm not entirely
> sure this is a good idea.
> 
> Did you guys discuss this?

Not so much as "discuss". I personally try to avoid introducing more state in MI,
at all costs. That's why for commands wishing to operate on a given thread group,
the --thread-group option will be required. Presently, only -exec-continue and
-exec-interrupt seem to need this, though.

- Volodya