-
|
Hello, I work with devices with very limited memory and strict real time constraints so unwinding the stack in situ is a tough challenge. However, I dump a portion of the stack whenever a crash occurs. I was wondering if unwinding a stack dump with the help of the DWARF debug information (generated at compile time but stripped from bin) was a use case that Libunwind is designed to handle ? The documentation seems to only mention local/remote unwinding of running processes. JDEL |
Beta Was this translation helpful? Give feedback.
Replies: 1 comment
-
|
libunwind has the coredump remote for unwinding from ELF core files. A stack dump is insufficient to unwind because you also need to be able to link instruction addresses back to the ELF file they were loaded from, which will lead you to be able to find the DWARF tables in the ELF file itself or in the stripped debug data file. It's possible to get backtraces from only partial core dumps but you need at least the stack, the processor state, and the load tables. Some of these are very OS-specific and if you're not using one of the supported OSes (eg. you're using an RTOS executive) you may need to do some porting work on libunwind to teach it about specifics. |
Beta Was this translation helpful? Give feedback.
libunwind has the coredump remote for unwinding from ELF core files. A stack dump is insufficient to unwind because you also need to be able to link instruction addresses back to the ELF file they were loaded from, which will lead you to be able to find the DWARF tables in the ELF file itself or in the stripped debug data file. It's possible to get backtraces from only partial core dumps but you need at least the stack, the processor state, and the load tables. Some of these are very OS-specific and if you're not using one of the supported OSes (eg. you're using an RTOS executive) you may need to do some porting work on libunwind to teach it about specifics.