- 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
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.
This patch adds more usage of the IProcesses service. I believe the patch is
backwards compatible with our 1.0 release (not with the latest HEAD). The
patch does the following:
1- cleanup context hierarchy to become:
MIControlDMContext
|
MIProcessDMC (IProcess)
MIExecutionGroupDMC __/ |
(IContainer) |
| MIThreadDMC (IThread)
MIExecutionDMC _____/
(IExecution)
Notice how I put MIControlDMContext at the top.
The create*DMC methods have been updated accordingly.
The constructors of the MI*DMC classes have been updated accordingly.
2- Deprecated GDBRunControl.getThreadData() and GDBRunControl.getProcessData()
and have GdbThreadFilterEditor and ThreadVMNode use IProcesses instead.
3- because of (2) I was able to remove IGDBRunControl and GDBRunControlNS
completely.
4- Made MIProcesses.getExecutionData() fetch the thread data using
CLIInfoThreads as is done (but deprecated) in GDBRunControl.getThreadData()
5- Added a cache and event listeners to MIProcesses to cache CLIInfoThreads.
6- Update MIRunControlEventProcessor and CLIEventProcessor to use
MIControlDMContext as their top context instead of IContainerDMContext
If no frame context is provided in an expression, but an execution (thread) is present, then we define the expression to belong to the top-most frame of that thread.
The Register unit tests made calls to createExecutionContext outside the
executor. This change fixes this and also one register test that didn't do what
it was meant to do.
When setting ATTR_WORKING_DIRECTORY in the launch (which was ignored before Bug 236058), we must now use an absolute path. The ATTR_WORKING_DIRECTORY was not actually used for the Breakpoint tests, so I removed it.
Support for Restart button.
The steps to restarting the inferior are the following:
1- Create a new PTY and tell GDB to use it
2- Create a new MIInferiorProcess object which uses the new PTY
2.5- Have the CLIEventProcessor use the new MIInferiorProcess
3- Restart the inferior using -exec-run
4- Remove the previous inferior Process from the launch
5- Add the new inferior Process to the launch (which will trigger the use of
the new PTY streams)
This change supports the Restart function, including the above steps to perform the proper cleanup. The code to start the inferior has been extracted from the FinalLaunchSequence and put in GDBControl to allow sharing between start and restart. Also, the code to create the CLI and inferior process objects has been extracted from the GdbLaunchDelegate and put in GDBControl to to allow sharing between start and restart.
There only interface change that is not in a provisional interface is the
addition of resetInferior() to CLIEventprocessor which is backwards compatible.
Read the gdbinit file as specified by the user. It does not specify at the command line as the CDT does it, but instead sources it as a GDB command. I believe this allows for easier specialization of the launch.
Moved the packages org.eclipse.dd.gdb.* to
org.eclipse.dd.gdb.internal.provisional.*
since it's expected that these classes are likely to need substantial
changes in not too distant future.
The JUnit launch now re-uses (without any changes) the standard DSF launch sequence. The problem then became that the tests would start too fast, before the suspend event was received. To address this, I added a wait for the Suspend event in the BaseTestCase.baseBeforeMethod() which runs before every test.
Moves the code out of org.eclipse.dd.gdb.launch.ui into
org.eclipse.dd.gdb.ui to allow people to extend the classes without taking in the extensions defined by org.eclipse.dd.gdb.launch.ui
The point of having an org.eclipse.dd.gdb.launch plugin was to allow other people to ignore this plugin and not have the standard DSF launches appear.
However, the DSF launch classes can still be useful to those people as they can be extended. Therefore, the launch code should not be in org.eclipse.dd.gdb.launch, but put back in org.ecipse.dd.gdb
