2012-02-10 20 views

Respuesta

12

De acuerdo con este post < http://codingrelic.geekhold.com/2009/05/pre-mortem-backtracing.html>,

También en algunas arquitecturas, incluyendo a mi querida MIPS, sólo __builtin_return_address(0) obras. MIPS no tiene puntero de marco, por lo que es difícil volver a subir la pila. El cuadro 0 puede usar el registro de dirección de retorno directamente. Si ARM tampoco tiene un puntero de marco, esto explicaría la limitación.

Véase también http://gcc.gnu.org/onlinedocs/gcc/Return-Address.html.

+6

En el ARM, la dirección de retorno se pasa en el registro 'R14', y es deber del destinatario de llamar para guardarlo al llamar a otra función. Por lo tanto, incluso con un puntero de marco, no hay garantía de que la dirección de retorno esté almacenada en la pila. –

+3

De hecho, cuando la dirección de devolución está guardada en línea en lugar de guardada en la pila por la instrucción de llamada, en general es imposible encontrarla. Debería haber una forma de usar los datos de desenrollado/depuración de dwarf2, pero eso requeriría que '__builtin_return_address' sea una llamada a una biblioteca de carga pesada en lugar de una construcción trivial ... –

+1

Por cierto, resolví este problema de rastreo de pila en ARM utilizando [-finstrument-functions] (http://gcc.activeventure.org/Code-Gen-Options.html) que se invocan en cada entrada/salida de función. Hay gastos generales, por supuesto, pero es aceptable para mí. (Y existe el atributo 'no_instrument_function' donde se requiere la velocidad máxima de llamada ...) –

4

Backtrace en ARM es difícil. La función Glibc backtrace funciona en estos días, pero necesita un compilador/glibc actualizado, y debe haber construido todo con -funwind-tables. GDB también tiene problemas sin información de depuración.

+0

¡Gracias por mencionar las tablas de runwind! Mis backtraces en ARM siempre fueron de profundidad 1 hasta que habilité este indicador de compilación. Usando GCC 4.3.2. – jfritz42

Cuestiones relacionadas