Rockbox.org home
release
dev builds
extras
themes manual
wiki
device status forums
mailing lists
IRC bugs
patches
dev guide



Rockbox mail archive

Subject: Re: ARM backtrace

Re: ARM backtrace

From: Amaury Pouly <amaury.pouly_at_gmail.com>
Date: Sat, 1 Oct 2011 14:24:28 +0200

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
- 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

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

Amaury Pouly


2011/10/1 Marcin Bukat <marcin.bukat_at_gmail.com>

> Hello folks,
> http://www.rockbox.org/tracker/task/12302 adds backtrace log to the
> panic screen on ARMs. This is simple port of
> http://www.mcternan.me.uk/ArmStackUnwinding/. The approach to take
> this backtrace is not perfect and has limitations BUT it doesn't need
> any special symbols or something to unwind stack frames. I am aware
> that the code itself would need some polish (unneeded typedefs, dos
> line ends etc.) but first I am interested if we want something like
> this at all. I played a bit with this inserting asm snippet causing
> data abort in various places and produced backtrace looked reasonable
> - still more tests needed.
>
> wo
>
Received on 2011-10-01

Page template was last modified "Tue Sep 7 00:00:02 2021" The Rockbox Crew -- Privacy Policy