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: Tue, 17 Jun 2008 14:32:06 -0400
- Subject: RE: Multiprocess MI extensions
> > 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).
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.
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?
Thanks
Marc