Seeing a call stack unwinding issue with ARM compiler using FreeRTOS. Based on my understanding, It seems that GDB when unwinding the call stack not finding the end of frame in the stack and still looking further which causes GDB to go into infinite to check for the end of frame in stack.
One of suggestion was to set the link register to 0 by setting configTASK_RETURN_ADDRESS to NULL. But even after this, issue is seen with ARMC6 compiler.
Appreciate any help on this…
This seems more like a question for GDB maintainers. What does the call stack look like when you put a breakpoint somewhere in main before the FreeRTOS scheduler is started? Whatever is that last function in that callstack, can you try setting configTASK_RETURN_ADDRESS to the same?
Thanks Gaurav for your response.
I tried setting configTASK_RETURN_ADDRESS to 0 but the timer task created during scheduler start goes into infinite loop of having same call stack. Hence, after sometime it gives strange call stack during debugging
It may not be a debugger issue after all. The ARM architecture provides so many obfuscating optimization possibilities that there may no discernible relationship between source and assembly code. The same phenomenon holds true on other debuggers as well. There is inlining, unfolding, tail recursion elimination, mode transitions… One thing you may want to try is build your code with optimizations disabled (-O0) and compare your stack frames. You are in for a number of surprises…
Maybe a silly question, but is the ARM toolchain compatible with your gdb ?
In other words is the gdb you’re using provided by ARM along with their compiler ?
I was using -O1 optimization level for the debug build but setting it to -O0 I dont see an issue. But is it hiding some issue or for the call unwinding to work optimization level must be set to -O0?
Yes. GDB is provided by ARM along with the compiler.
Then it is exactly the issue mentioned by @RAc.
It is common to build code with no optimization for debugging as it ensures better relationship between source and the generated assembly. Unless, you trying to debug an issue that only happens with optimization enabled, it is okay to keep optimization turned off for debugging.
okay. The reason of not going with complete optimization disabled is it consumes more code space and has an issue of fitting into the hardware. Hence, we used -01. But I still have a question does call stack unwinding have relation with the optimization level?
yes, it does. Under different optimizations, the call stack may be very very different. “Unwinding” as in “a debugger trying to determine the call sequence and matching it against source code” becomes a very challenging and error prone issue for a debugger.
-Og could be a good compromise supported by GCC. If the image still fits into your target.