I have moved ISymbolDMContext, IBreakpointsTargetDMContext, ISourceLookupDMContext,
ISignalsDMContext, IDisassemblyDMContext back to GDBControlDMContext.
Maybe later, depending on GDB's final solution, we can move things back.
So, GDBControlDMContext is no longer an IMemoryDMContext or an IContainerDMContext. Those interface are implemented by GDBContainerDMC.
IContainerDMContext with the IProcessDMContext as its parent, since the debugger is attached to the process.
We had agreed to keep IRunControl contexts out of IProcesses, so this patch
simply allows debugNewProcess() to return any context (IDMContext.)
- IMIExecutionGroupDMContext to IMIContainerDMContext
- MIExecutionGroupDMC to MIContainerDMC
- createExecutionGroupContext to createContainerContext
- ExecutionGroupStartedDMEvent to ContainerStartedDMEvent
- ExecutionGroupExitedDMEvent to ContainerExitedDMEvent
- makeExecutionGroupDMCs to makeContainerDMCs
- bunch of local variables groupDmc to containerDmc
MIRunControlEventProcessor_7_0. It also reverts CLIEventProcessor and
MIRunControlEventProcessor to the logic needed for a GDB pre 7.0 (the way we released it in 1.0)
MIThreadExited and MIThreadCreated events are now only issued once.
Running events are also issued only once, however, it needed a little
gymnastics to keep the same functionality. Before 7.0, what we did was trigger the event once a continue, step or next command was executed; this allowed to also know the type of command that caused the running event. With the new MI event "*running", we don't know the type of the command that caused it.
What I did was, like before, when a continue, step, next command is issued, I
store the type of the command, and once the *running event occurs, I use that
type. I do this using a global MIRunControlEventProcessor_7_0.fLastRunningCmdType
When issuing such a continue, etc command through the CLI, we still need to somehow remember the type of the command. This is under discussion in the bug.
The project is still mandatory for two reasons:
1- platform does not allow an empty project
2- Source lookup was not able to find the code with an empty project; since the platform did not allow for an empty project anyway, I did not investigate the
source lookup issue.
Cleanup of MICommands that had --thread/--stack implemented directly in the class.
MIStackNS is no longer needed, and its only
remaining difference (checking if the thread is suspended) has been merged into
MIStack.
Adds a GDBMultiProcesses service which uses the new GDB -list-thread-group commands. Also adds some support for =thread-group-created/exited events.
Since the public GDB is not ready yet, I have commented out the instantiation of this new service, for now.
More use of IProcesses. In the weekly meeting, we had agreed that the RunControl service would make use of IProcesses to list executionContext. To do this, it is the IProcesses service that will now create the MIExecutionDMC, which is newly declared in MIProcesses. Doing this I was able to get rid of IMIRunControl, and I introduced IMIProcesses.
Also, we agreed that all RunControl use of IProcesses should be kept out of MIRunControl and put only in GDBRunControl. This is because other backends using MI will probably need a more sophisticated Process service. I still have to move the use of IProcesses out of MIRunControlNS
I also cleaned up the RunControl and GDBProcesses unit tests.
I also started spreading the use of a String as a ThreadId, while keeping things backwards compatible.
when using GDB6.6, if the solib-search-path is used, the launch will fail because the -gdb-set sysroot command will fail. The concept of sysroot seems to have been introduced with GDB 6.7
Let's comment it out since it was used only as a safeguard.
