Bug 342358

Description Marc Khouzam 2011-04-09 21:04:05 EDT

I set the option not to kill GDB when the last inferior terminates.

1- if I kill the inferior while it was suspended, the IRunControl service of course considers it as suspended.
2- if I kill the inferior while it was running, we first interrupt it to be able to send the kill command; so, again the IRunControl service considers it as suspended.
3- if I let the inferior run to completion, we actually get a *stopped event, and yet the IRunControl service considers it as not suspended.

The reason for #3 is that we send an MIInferiorExited event instead of a stopped event.  I don't think we need MIInferiorExited anymore, but until that is cleaned up properly, I need a way to know that the inferior is 'suspended'.  This is important to know that GDB is reachable.

For example, if I let the inferior run to completion and then try to remove a breakpoint, we will mistakenly try to interrupt the target repeatedly.  This was not a problem before CDT 8.0 because previously the IMIRunControl.executeWithTargetAvailable, would get the list of processes to know if the process was suspended, but since there was no process once the inferior was run to completion, it would know that it did not need to interrupt the target.  With CDT 8.0, the breakpointTargetDmc is a process, so we no longer get the list of processes but rely directly on IRunControl.isSuspended().  This is why we need to properly handle the suspended state, for all cases.

This does not happen in non-stop, thanks to the fix of bug 341396, which considers a process with no threads as suspended (this implies both a process that is not started and one that is terminated).