We have a strange error with our debuggers when running the debugger on a phone in release mode. Whether we are using gdb or lldb with xcode 4.3.3, the code will land on breakpoints even though the code’s PC is not really pointing at that spot.
Example fake code:
if (true) {
// set breakpoint-A here
} else {
// set breakpoint-B here
}
// set another breakpoint-C here.
It will land in breakpoint-B and then jump to breakpoint-A.
Is the cause because we are in “release” mode and it’s optimizing?
Thanks!
Yes, there are three things going on here: When you build in release mode, the compiler is doing optimized code generation. The compiler may change the order that source lines are compiled into the program (as long as it doesn’t change the meaning of the code), instructions between different source lines may be intermixed or rearranged, and finally there can be problems with the line table that the compiler emits.
Imagine two source lines, each which turn in to 8 assembly language instructions. The compiler may rearrange these 16 instructions (as long as it doesn’t change the results of them) to keep the CPU(s) running most efficiently. But in this situation, what instruction should the compiler say is equivalent to line 1? and what instruction should the compiler say is equivalent to line 2?
With optimized code debugging, if you’re debugging at a source code level, you have to live with the reality that the “currently executing source line” is going to bounce around a lot while you step through your program. Variables that seem to be in scope will appear and disappear at nonobvious times. The compiler’s ways are tricky and hard to understand. You need to debug with the assembly language code in front of you (or a source + assembly display) to really follow what’s happening.
There are improvements that compilers and debuggers can make to improve optimized code source-level debugging but it will probably always be a little hard to follow.