mirror of
https://github.com/eclipse-cdt/cdt
synced 2025-04-29 19:45:01 +02:00
1333b20ec5
When a breakpoint is set directly at the start of a function, and you step into that function, gdb <= 7.3 will generate a "stopped" event with two reason fields. The first to indicate that the step range ended and the other to indicate that a breakpoint was hit. While this is not really correct from gdb to include the same field twice in a single event, the implementation of MIRunControlEventProcessor_7_0 will generate two distinct MIStoppedEvent events. This confuses the step-into-selection mechanism, who will issue two finish/step-return instead of one. For all gdbs, we will have a test where the breakpoint is a not at the function entry. Then, for gdb > 7.3, we will have the same test but with the breakpoint at the function entry, to test that particular case. This case is known to be broken with gdb <= 7.3 (rather old) and will stay that way unless somebody feels like fixing it. So, for both: - atDoubleMethodStopAtBreakpoint - atDoubleMethodSkipBreakpoint I extracted the code in a common function which takes in parameter the line to set the breakpoint at. Change-Id: I2ae4bc527afe0ab195e9b066279ed92f74d652f3 Signed-off-by: Simon Marchi <simon.marchi@polymtl.ca> Reviewed-on: https://git.eclipse.org/r/38717 Tested-by: Hudson CI Reviewed-by: Marc Khouzam <marc.khouzam@ericsson.com> Tested-by: Marc Khouzam <marc.khouzam@ericsson.com> |
||
|---|---|---|
| .. | ||
| org.eclipse.cdt.dsf.gdb | ||
| org.eclipse.cdt.dsf.gdb.multicorevisualizer.ui | ||
| org.eclipse.cdt.dsf.gdb.tests | ||
| org.eclipse.cdt.dsf.gdb.ui | ||
| org.eclipse.cdt.examples.dsf.gdb | ||
| org.eclipse.cdt.gnu.dsf-feature | ||
| org.eclipse.cdt.gnu.dsf.source-feature | ||
| org.eclipse.cdt.gnu.multicorevisualizer-feature | ||
| org.eclipse.cdt.tests.dsf.gdb | ||