This is the bug/patch tracker for Rockbox. Click here for more information.
Quick links: Bugs · Patches · Rockbox frontpage
FS#12302 - Add backtrace to the panic screen on ARM
Attached to Project:
Rockbox
Opened by Marcin Bukat (MarcinBukat) - Friday, 30 September 2011, 21:38 GMT+2
Last edited by Marcin Bukat (MarcinBukat) - Saturday, 14 April 2012, 18:21 GMT+2
Opened by Marcin Bukat (MarcinBukat) - Friday, 30 September 2011, 21:38 GMT+2
Last edited by Marcin Bukat (MarcinBukat) - Saturday, 14 April 2012, 18:21 GMT+2
|
DetailsPort (rather trivial) of unwarminder http://www.mcternan.me.uk/ArmStackUnwinding/
This gives backtrace in Panic screen in addition to PC value 
unwarminder_v1.diff
(94.6 KiB)
b/firmware/SOURCES | 7 b/firmware/target/arm/system-arm.c | 7 b/firmware/target/arm/unwarminder/client.c | 119 +++ b/firmware/target/arm/unwarminder/client.h | 83 ++ b/firmware/target/arm/unwarminder/get_svc_sp.c | 15 b/firmware/target/arm/unwarminder/get_svc_sp.h | 1 b/firmware/target/arm/unwarminder/types.h | 39 + b/firmware/target/arm/unwarminder/unwarm.c | 183 +++++ b/firmware/target/arm/unwarminder/unwarm.h | 178 +++++ b/firmware/target/arm/unwarminder/unwarm_arm.c | 701 +++++++++++++++++++++ b/firmware/target/arm/unwarminder/unwarm_thumb.c | 740 +++++++++++++++++++++++ b/firmware/target/arm/unwarminder/unwarminder.c | 78 ++ b/firmware/target/arm/unwarminder/unwarminder.h | 160 ++++ b/firmware/target/arm/unwarminder/unwarmmem.c | 175 +++++ b/firmware/target/arm/unwarminder/unwarmmem.h | 57 + 15 files changed, 2540 insertions(+), 3 deletions(-) |
This task depends upon
Closed by Marcin Bukat (MarcinBukat)
Saturday, 14 April 2012, 18:21 GMT+2
Reason for closing: Accepted
Additional comments about closing: commited as b4eab599513324dcaffa4c5693345ae11f3f9725
Saturday, 14 April 2012, 18:21 GMT+2
Reason for closing: Accepted
Additional comments about closing: commited as b4eab599513324dcaffa4c5693345ae11f3f9725
I think it would be nicer to compile the unwinder as a separate lib and link to it later, perhaps with an compile time switch.
2) added backtrace() to panicf()
backtrace start
A: 0x000C0000
backtrace end
It makes no sense. According to rockbox.map, the address is in .bss from apps/tagtree.o. Also, there can't only be one function on the stack. I don't expect memory to be trashed at this point. Rockbox would continue to function normally if it wasn't for the panicf(). A second attempt gives the same result.
I would love to see a working backtrace. For example, a backtrace could maybe help me figure out
FS#12423.Edit: Oops, I forgot about -fomit-frame-pointer. However, adding -fno-omit-frame-pointer after the -O just gives me an empty backtrace instead. I'm unable to test without -O because due to unrelated compile errors which happen even in unmodified svn. I'm running r31107 on a 5G iPod with 32MB RAM.
Try to make an swi, that should result in UIE being called with backtrace.
I'm not sure what's wrong in panicf(). Passing the return address (LR) as PC and the current SP within panicf() as SP seems wrong. That's a PC value from the function that called panicf(), and an SP value that has been decreased by panicf(). Shouldn't both correspond to the same moment? However, I haven't been able to make it work based on this assumption.
Little explanation as the approach is hacky (IMO) and maybe someone comes with better idea. The main problem is that we need matching SP,PC input values for unwinder AND PC should be after panicf(). I don't know if this is the problem with panicf() itself being noreturn or unwinder shouldn't enter itself. The situation is further complicated by the fact that panicf() is variadic function. So to get consistent SP,PC I created naked function wrapper around panicf() just to save SP before entering actual panicf() (this should be the same as just after returning) and I save it to r4 register as this one doesn't hold valid parameters to function being wrapped. Then wrapper simply branch to actual panicf(). At the very beginning of panicf() I copy r4 to some local variable and get PC just after the function with gcc intrinsic function __builtin_return_address(). Although this seems to work I see potential problem that compiler might reorganize the code during optimization and trash our hackly saved in r4 SP value.
5.5kb is fine on targets with plenty of memory. This should be included conditionally, based on MEMORYSIZE, maybe for 8 and above.
I don't know why -O was chosen. When there's plenty of memory, such as 32MB on the 5G iPod, energy savings from more efficient code are larger than energy savings from enlarging the buffer via -Os. For best results, optimization settings could be adapted to how often code is used. For example, it's possible via "#pragma GCC optimize" and the optimize function attribute. (Of course, adding those throughout Rockbox would be a significant amount of additional work.)
The attached patch to firmware/target/arm/unwarminder/client.h formats the output to fit the e200 screen. Further optimizations may be needed for other small screen targets (i.e.clip).