Rockbox mail archiveSubject: Re: ARM backtrace
Re: ARM backtrace
From: Amaury Pouly <amaury.pouly_at_gmail.com>
Date: Sat, 1 Oct 2011 15:03:36 +0200
> I wouldn't take 'memorized' backtraces seriously.
I you would be right :)
In theory we can 1) compress the map, 2) resolve only function names
> (not all symbols)
I've only kept the function names, keeping all the symbols would be insane.
Compression is an interesting idea. With lzma -9, it goes down to 16Kib but
of course that would mean we need a decompressor so one would need to take
its size into account (I think there is a light lzma decompressor which fits
in a few Kb).
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)
Yes I'm aware of this but hopefully asm functions will rarely be the cause
and are usually tail calls (they don't call any other function). But if we
want perfect analysis, this will require much more code.
Received on 2011-10-01