TasksTasksARMGenericBacktraceSupport » History » Version 2
Anonymous, 02/19/2016 10:48 PM
| 1 | 1 | ||
|---|---|---|---|
| 2 | |||
| 3 | 2 | h2. ARM Backtracing support |
|
| 4 | |||
| 5 | |||
| 6 | 1 | ||Mentor ||Holger Freyther || |
|
| 7 | ||Skills ||C and Assembly || |
||
| 8 | ||Length ||20 days || |
||
| 9 | |||
| 10 | 2 | ||
| 11 | h3. Goal |
||
| 12 | |||
| 13 | 1 | Writing firmware (specially without JTAG) can be error prone and one can have various kind of crashes (full stack, running out of memory, etc). Tools like mudflap, valrgind might not be usable. One thing that would help is to have a generic backtrace framework. On illegal memory access the ARM core will jump to a signal handler (e.g. data abort, illegal instruction, etc.) we should be able to branch to the error handler from there before the reset |
|
| 14 | |||
| 15 | 2 | ||
| 16 | h2. Approach |
||
| 17 | |||
| 18 | * Compile the firmware with framepointers. This way it will be possible to find the frame, previous frame, previous previous frame. |
||
| 19 | * Change the firmware to setup a stack for the abort handlers. |
||
| 20 | * Create a C routine that given the address of a framepointer will unwind the stack and print the addresses |
||
| 21 | * Write a script using objdump to convert the addresses back to functions and line numbers. |
