This is the mail archive of the gdb@sourceware.org mailing list for the GDB project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]