Get the latest tech news
MIPS stacktrace: an unexpected journey
Automatically receiving a stacktrace when your C program crashes isn't rocket science. But this time it was more difficult than I expected. This is a short recollection of the things I found out few years ago. This post assumes that the reader has some basic knowledge about functions' calling conventions, CPU registers, and assembly. Some context A C program running on Linux was randomly crashing on one specific embedded device deployed on the other side …
It turns out that backtrace(3) does the same thing that too many blog posts on the Internet recommend to do: unwind the stack using the frame pointer register to figure out the position of the previous function's return address. This makes perfect sense, the frame pointer(aka$fp or$30 on MIPS) is usually a register designed to help debuggers to refer to local variables and other information stored on the stack (e.g. the previous function return address) using constant offsets. You may not like the answer (or maybe you will) but the only way to know where the beginning of the stack frame is... is to jump into the actual code of the function and parse the opcodes to figure out how much$sp was decremented by the compiler.
Or read this on Hacker News