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.
*org.eclipse.cdt.debug.mi.core/MISession.java
* org.eclipse.cdt.debug.mi.core.cdi/BreakpointManager.ajva
*org.eclipse.cdt.debug.mi.internal/iu/{StandardGDBDebuggerPage.java,MIUIMEssages.properties}
220045 Debuger is stopping on non-existing breakpoints for files with same name
Patch from Elena
*org.eclipse.cdt.debug.internal.uui.propertypages/CBreakpointPreferenceStore.java
*org.eclipse.cdt.debug.internal.uui.propertypages/CBreakpointPropertyPage.java
221408 nor P3 Wind cdt-debug-inbox@eclipse.org NEW Ability to move breakpoints manually to a different line
Patch from Elena
* org.eclipse.cdt.debug.mi.core.cdi/SourceManager.java
221944 nor P3 Wind cdt-debug-inbox@eclipse.org NEW Cannot display long long int as hex
Patch from Elena
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
