Examining local variables returned function

Question

I have a coredump of a process that has crashed (hard to reproduce).

I have figured out that something goes wrong in a function that has just returned (it returned a NULL pointer rather than a non-NULL pointer).

It would be of great help for me to know the contents of the stack variables in that function. I think on most architectures, returning from a function just means changing the stack pointer. In other words, those values are still there (below the stack pointer then if we take x86 as an example).

Can anyone confirm my reasoning is correct and maybe provide an example how do this with gdb?

Does my reasoning also hold for MIPS ?

Answer 1

Local variables might have been stored on stack, but not necessarily. If there is only a small number of variables that fit into registers and code is optimized, then local variables were never saved on stack. Depending on calling convention used, final values of local variables may still persist in registers.

Disassemble the function in question (you can use objdump -dS to do this, so you can easily correlate source). See how local variables were accessed . Were they stored in memory or registers? Were registers already restored to their value relevant for caller?

If original register value was not restored, you can just examine the register that was used to store local. If it was already restored, then it's probably lost.

If local values were stored to stack, then function prologue (first instructions) should tell you how stack and frame pointer were manipulated. Taking into account that call also saved to stack (PC saved) you can calculate the value of stack/frame pointer used in that function. Then use x to examine memory locations.

Depending on called function, you could also be able to examine its arguments (when called) and recalculate the value of local variables.