Checking Return Functions of Local Variables

Question

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

I found out that something went wrong in the function that I just returned (it returned a NULL pointer, not a non-NULL pointer).

It would be very useful for me to know the contents of the stack variables in this function. I think that on most architectures, returning from a function simply means changing the stack pointer. In other words, these values ​​still exist (below the stack pointer, if we take x86 as an example).

Can someone confirm that my reasoning is correct and, perhaps, give an example of how to do this with gdb?

Is my reasoning supported for MIPS?

Answer 1

Local variables could be stored on the stack, but not necessarily. If there is only a small number of variables that fit into registers, and the code is optimized, then local variables are never stored on the stack. Depending on the conditional convention used, the final values ​​of local variables may be stored in registers.

Parse this function (you can use objdump -dS so you can easily map the source). See how local variables were available. Have they been stored in memory or registers? Have registers already been restored to their value relevant to the caller?

If the original register value was not restored, you can simply examine the register that was used to store the local one. If it has already been restored, it is probably lost.

If local values ​​were saved onto the stack, then the prolog function (first instructions) should tell you how to manipulate the stack pointer and the frame. Taking into account that the call is also saved on the stack (PC saved), you can calculate the value of the stack / frame pointer used in this function. Then use x to view memory locations.

Depending on the function being called, you can also examine its arguments (when called) and recalculate the value of local variables.

Answer 2

You can see a local variable that is not optimized with:

info locals 

It may not work in a function that is already being returned. If you can run this program again, try setting a breakpoint just before the function returns.

Otherwise, you can manually examine the stack using x/x and info register to find out the address of the stack pointer.

Then you can view the stack with up and down .