RE: Multiprocess MI extensions

["Marc Khouzam" <marc dot khouzam at ericsson dot com>]

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

There are a couple of enviroment variables that may apply to a
given thread-group.  I admit that these commands bring
up other questions about how to deal with multi-process
debugging and that I may be bringing this up a little early.
I'll list the commands anyway, but it is just to start the ball
rolling (although I'm sure the ball is rolling already :-))

-file-exec-and-symbols (and the like)
-exec-arguments (DSF uses '-gdb-set args' instead)
-environment-cd
-inferior-tty-set (although this can apply to all inferiors
as we discussed with Dan in a recent thread)
-exec-abort (or kill)

The question of exit code also comes up, although I'm not very
familiar with it, so I don't know how it applies.

This does not look too bad, now that I see it listed :-)

Marc