GDB cannot step over empty while(1) loop
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
GNU Arm Embedded Toolchain |
Won't Fix
|
Undecided
|
Terry Guo |
Bug Description
Probably related to https:/
Attempts to single step an empty loop always fail, the loop is entered but not exited after one iteration.
NB: The same scenario works perfectly well with the 386 GCC on Linux, single stepping empty loops behave as expected.
I tried with 4.8 and the latest 4.9, and the problem is the same. I also tried with -O0 vs -Og, -g3, -dwarf-4 vs toolchain default and no difference.
I encountered the problem when using Eclipse, but manually starting the GDB client and entering 's' or 'n' showed the same behaviour (entering the infinite loop).
Switching Eclipse to assembly mode works, only the C debug information seem not appropriate.
When you test be sure you have some code between the beginning of main and before the loop, otherwise if you place a breakpoint at main, this will be in fact a breakpoint inside the loop, and single stepping will halt due to the breakpoint. A more general rule would be to do not place a breakpoint on the instruction before the empty loop.
If you need more details on how to reproduce the problem, please let me know.
Regards,
Liviu
p.s. In case you wonder why someone would single step an empty loop, please be aware that most project templates generate such constructs, where people should fill in the actions. Most people try a debug session with the empty loop, and are very confused by the debugger not single stepping properly.
Changed in gcc-arm-embedded: | |
assignee: | nobody → Terry Guo (terry.guo) |
Could you add code of the working linux PC scenario, please? Sorry, but I do not believe it is working. GDB will not change the program flow by stepping. "step over" means it will halt when the instruction at the line you step over has finished and the control flow reaches the next line. Since a line with an infinite loop is never done, step over will simply not work.
As a workaround you could use a boolean guard, which you modify while debugging to break out of the loop.