Community
Participate
Working Groups
When applying a thread filter to a previously unfiltered DSF-GDB line breakpoint, the MIBreakpointsManager#modifyBreakpoint() method will attempt to create a new GDB line breakpoint for each thread on which the breakpoint should trigger. If this is successful, the old unfiltered GDB breakpoint (at the same source line) is then deleted. The above behaviour works well for older GDB, but with more recent GDB (7.4.1, 7.5.1, and possibly other versions) the deletion of the old breakpoint appears to affect behaviour of the new breakpoint(s) at the same source line. I can reproduce this at the GDB command line: > (gdb) break main.c:5 > Breakpoint 1 ... > (gdb) break main.c:5 thread 1 > Note: breakpoint 1 (all threads) also set at ... > Breakpoint 2 ... > (gdb) delete 1 > (gdb) Now the "info break" command reports that breakpoint 2 is enabled for thread 1 but it is never triggered with recent GDB. If breakpoint 1 is deleted before breakpoint 2 is created then breakpoint 2 will be triggered (the problem is not observed). This issue was discovered using a GDB remote target (arm-eabi). It may or may not be reproducible using a local debug session. This looks like a GDB bug, but a workaround in CDT would be useful.
I can confirm that this issue also affects the debugging of local pthread applications using the standard "GDB (DSF) Create Process Launcher" with native GDB 7.4.1 on Linux. To ensure correct breakpoint behaviour, it is necessary to delete the old GDB breakpoint(s) *before* creating the new one(s) at the same location. The current CDT breakpoint manipulation code works correctly with native GDB 7.3.1.
