This is the mail archive of the
gdb@sourceware.org
mailing list for the GDB project.
Re: Multiprocess MI extensions
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