Use the generic IDMContext instead of IContainerDMContext because some debuggers may not have a run control service
Replace IThreadDMData.getDebuggingContext() with method getDebuggingContext()
some improvements to the IProcesses interface where needed:
1- getRunningProcesses() should take an IContainerDMContext as a parameter to prepare for multi-core/multi-processor debugging.
2- attachDebuggerToProcess() should return an IContainerDMContext as part of the requestMonitor. This is because, once a process is attached to, it will then need to have a container context to use the RunControl service.
3- getProcessesBeingDebugged() should take an IContainerDMContext as a parameter to prepare for multi-core/multi-processor debugging. Also, it should return an array of IContainerDMContexts as part of the requestMonitor; this is because, processes that are being debugged should have a container context to use the RunControl service.
Using protocol 'mi' will use the latest mi version available to GDB. This is somewhat dangerous, as we actually support mi2. It is safer to specify mi2 as our version.
This patch removes all dependencies to the CDT debug feature.
It copies Extensions that were defined in the CDT to DSF.
I have tested it with an Eclipse that did _not_ have the CDT debug feature, and things seem to work as they should. There was a few files copied from the CDT that may need some cleanup, but I'll leave that for later.
The CDT code we re-use uses the CDT constants that I copied
to DSF, but uses them with a CDT prefix. I had changed that prefix for DSF. I
put the prefix back so that the constants would match.
Update GdbLaunchDelegate to no longer require anything from
org.eclipse.cdt.launch.
Also triggers a build when necessary before launching, as the CDT does.
Also introduces a LaunchMessages class which uses a resourceBundle for
launch messages that has been added as org.eclipse.dd.gdb.internal.provisional.launching.LaunchMessages
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.
We only support GDB 6.6 and higher, from what I can see,
-interpreter-exec is always available (I tried with mi1 m2 and m3 on GDB 6.6).
Therefore, we can simplify the launch by removing the
CheckInterpreterConsoleStep.
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.
Adds the use of solib-search-path as done in the CDT (by filling the Shared Library subtab in the debugger tab of the launch).
Also adds the use of auto-solib-add as in the CDT.
Currently, DSF launches gdb with a <file> argument, which tells gdb where the
executable file and the symbols are. This is potentially restrictive to
someone wanting to extend gdb.
This change removes the <file> argument to gdb and uses -file-exec-file and
-file-symbol-file commands to set this parameter in the FinalLaunchSequence.
This has the exact same effect, but allows to easily override these commands by
using a tailored FinalLaunchSequence.
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 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
