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.
Debug traces were printed for out-of-band events when they were processed (processEvent()) and again when the next ResultRecord is received (processCommandDone()).
This fix only prints the ResultRecord in the processCommandDone() method.
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.
For a local launch, only gdb/mi debugger will be available, while for a remote launch, only gdbserver debugger will be available.
This is a temporary solution.
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.
