From: Marcin Bukat <marcin.bukat_at_gmail.com>
Date: Sat, 1 Oct 2011 14:50:34 +0200

2011/10/1 Amaury Pouly <amaury.pouly_at_gmail.com>:
> Hi,
> First thanks for the work, I definitely think backtrace is useful as you
> know. I would like to discuss a related subject at the same time: the one of
> symbols. Backtrace is a very useful tool because we produce a map during the
> build. I think it's worth thinking about displaying the symbol name rather
> than the adresses directly. Here are some pros and cons, please object if
> you disagree or want to add points:
>
> Pros:
> - Easier to read/memorize for most people. Say a crash happen and you don't
> have anything to write it down, then you're more likely to remember names
> than numbers and it can still be useful

I wouldn't take 'memorized' backtraces seriously.

> - It works for any builds and the user doesn't need to provide the map if
> it's a custom build for example. I know we don't really want to support
> custom builds but any crash report can be useful right ? Furthermore some
> users will fail to give the (right) version of rockbox and won't anwser to
> any request beyond the bug report. This solves the problem (but we could
> also simply print the version as part of the panic screen too).
> - Easier to work with, even for devs, you don't have to write down the
> numbers all the time to see where it is.
> - Not too difficult to implement, the code itself is really small
>
> Cons:
> - Binsize because we need to include a symbol map. I've map some tests and
> on a fuze+ build, the relevant symbol map would be ~50kb size which is not
> negligible
>
In theory we can 1) compress the map, 2) resolve only function names
(not all symbols)

> This remark aside, I think the small binsize of the backtrace (~5Kb) is
> worth it !
> Best regards
>
> Amaury Pouly

I should state the caveats of ported implementation I guess:
1) Code analysis is not 100% accurate - it means that it is possible
(although quite unlikely in case of gcc generated code) to miss some
function in backtrace. Hand written assembly can easily fool unwinding
engine though.
2) There is no other proof that the backtrace isn't broken than to
compare addresses to memmap (or dissasembly)
3) Since the code is evaluated forward, it will not produce backtrace
at all from undefined instruction exception most probably
4) To avoid the risk of infinite loops there is a counter how many
instructions to decode before giving up in searching for stack frame.
It is set to 1000 currently but it may come that we crashed in the
middle of some lengthy function and we will not see epilogue within
set limit of instructions. Since we call this from the state we will
not recover anyway, we can increase this limit at cost of possibly
longer time of taking backtrace. (1000 instruction limit gives instant
backtrace on my rk27xx).
5) The nesting depth is arbitrary limited to 32 calls (which should
not be a problem since I saw 7 calls at most when toying with this
unwinder and rockbox codebase)

wo
Received on 2011-10-01