This is the mail archive of the
gdb@sourceware.org
mailing list for the GDB project.
RE: Multiprocess MI extensions
- From: "Marc Khouzam" <marc dot khouzam at ericsson dot com>
- To: "Vladimir Prus" <vladimir at codesourcery dot com>
- Cc: <gdb at sources dot redhat dot com>
- Date: Wed, 18 Jun 2008 09:49:06 -0400
- Subject: RE: Multiprocess MI extensions
> > 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