ARMC6: To get the right stack trace, use -O0
#11431
Conversation
Verified that `-O1` does not make stack trace while `-O0` does.
|
Btw, if we change, we need to change also exporters for uvision (see #11212). We have From the reference:
Is this a reason for this PR? You can track it back. From the log, we are using O1 because:
Also client uses the same profiles as we now (@teetak01 updated it for 5.14) as I recall (consistency). |
|
What was your example code? If this is just a tailcall issue, because your calls are so simple, I wouldn't sweat it. A real use case wouldn't tailcall that much, so I would expect a real backtrace to largely make sense. But let's see this one. Killing tailcalls can greatly increases stack usage - I'd be wary of using a lot more stack just to make it more backtraceable. |
|
@andrewc-arm, thank you for your changes. |
|
@kjbracey-arm and @0xc0170 < True backtrace > Please note that though I tried to avoid tailcalls I was only able to get only one level increased from the previous run. < The stack dump > NOTE: If you search (#number) (which I manually added) you will be able to confirm that the stack dump matches with true callstack information. So I am neutral since I know how to debug, but I want to receive your opinion before closing this ticket. Could you please review my example code and is this what you expect to see in debugging mode? Also, consistency with GCC_ARM and IAR should be considered, for those toolchains, tailcall feature is turned off. Either we should enable or disable tailcall for all the toolchains in debug mode. Could you please share your opinion? |
I took a look at the PR you mentioned. Could you please confirm that PR also discuss about the mbed-os/tools/profiles/release.json Line 18 in 7d30107 -Oz option which looks like the maximum space optimzation (link).And the PR seems to be related with exporter and maybe not so much related with debug mode? Please confirm. Thanks!
|
In your example, almost every function call is an optimisable tailcall - that is a function that calls another function as the last thing it does. As far as I can tell, only You avoid tailcalls by doing something else after calling the inner function. There's a conflict here - between people who want to be able to routinely build a complete "debug" image and have it fit in their ROM and those who actually want to have it as debug as possible. The trend recently has been to nudge the "debug" profile to be a bit smaller. The limitations of O1 are known, and were already discussed when the O0->O1 change were made. I also have rarely been 100% satisfied with the O1 or Og options - they're often not as good as claimed. But I understand why people had problems with O0. I'm not convinced the existence of an in-built backtracer changes the results of the previous discussion. The results you're seeing here don't surprise me - I'm more surprised about how tailcally a test you managed to produce :)
I don't think we're making an explicit choice for that in any, are we? We're just going with each toolchain's "intermediate debug" option. That is part of the issue with choosing to do that - each chain is going to have made different choices on the compromises for their "intermediate" setting. I would be open to having an extra "full_debug" profile, but people are always free to flip to O0 themselves. It would help if we could select different options per-file, so the debug could be targetted, keeping total image size down |
|
Understood! Thanks for the feedback! Then all good. BTW. I modified the example code like this and got the result I want. < Real call stack > < The stack dump > NOTE: If you search (#number) (which I manually added) you will be able to confirm that the stack dump matches with true callstack information. Thanks for the guidance! |
|
Good to have this resolved, some users will find this discussion helpful (they might have the same question about "why O1"). |
Verified that
-O1does not make stack trace while-O0does.Description
Why required
Without this change,
ARMtoolchain's--profile debugbuild will not create stack trace. FYI, this is the gdb back trace result of-O1.With
-O1, this is the correct back trace acquired.It looks like ARMC6's
-O1level is quite optimizing than what we expect.FYI. Here is the related document.
http://www.keil.com/support/man/docs/ARMCC/armcc_chr1359124935804.htm
Pull request type
Reviewers
Reference
Release Notes