mirror of
https://github.com/eclipse-cdt/cdt
synced 2025-04-29 19:45:01 +02:00
Mirror of https://github.com/eclipse-cdt/cdt
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> |
||
|---|---|---|
| build | ||
| codan | ||
| core | ||
| cross | ||
| debug | ||
| doc | ||
| dsf | ||
| dsf-gdb | ||
| jtag | ||
| launch/org.eclipse.cdt.launch | ||
| llvm | ||
| lrparser | ||
| memory | ||
| p2 | ||
| qt | ||
| releng | ||
| remote | ||
| testsrunner | ||
| upc | ||
| util | ||
| visualizer | ||
| windows | ||
| xlc | ||
| .gitignore | ||
| pom.xml | ||