Find out function arguments value from stack pointer
Given stack pointer value, is it possible to determine the value of the passed arguments to the function? Where are the arguments stored in the stack frame. Lets say, executing gcc compiled ELF binary on x86 architecture on Linux platform: int foo(int a, int b) { ... } foo(a,b) is called from main() and I know the stack pointer(SP) value which is pointing to foo() now. How can I retrive the value of arguments a and b? If stack grows from smaller address to larger address, and arguments are passed right to left usingcdecl, can I obtain args value like this: b = *(SP + 1); a = *(SP + 2); The following program prints the value of functions args a, b using above arch and specifications. void foo(int a, int b) { int i; register int stackptr asm("sp"); int *sp = (int *)stackptr; printf("\n\ta=%d b=%d\n", a, b); for (i=0; i<16; i++) { printf("*(sp + %d) = %d\n", i, *(sp +i)); } } int main() { foo(3, 8); foo(9, 2); foo(1, 4); return 0; } The output of above code is: a=3 b=8 *(sp + 0) = 134514016 *(sp + 1) = 0 *(sp + 2) = 0 *(sp + 3) = 134513373 *(sp + 4) = 8239384 *(sp + 5) = 134513228 *(sp + 6) = 6 *(sp + 7) = -1076716032 *(sp + 8) = 134513456 *(sp + 9) = 0 *(sp + 10) = -1076715960 *(sp + 11) = 134513759 *(sp + 12) = 3 //value of arg a *(sp + 13) = 8 //value of arg b *(sp + 14) = 134513817 *(sp + 15) = 10612724 a=9 b=2 *(sp + 0) = 134514016 *(sp + 1) = 0 *(sp + 2) = 0 *(sp + 3) = 134513373 *(sp + 4) = 8239384 *(sp + 5) = 134513228 *(sp + 6) = 6 *(sp + 7) = -1076716032 *(sp + 8) = 134513456 *(sp + 9) = 0 *(sp + 10) = -1076715960 *(sp + 11) = 134513779 *(sp + 12) = 9 //value of arg a *(sp + 13) = 2 //value of arg b *(sp + 14) = 134513817 *(sp + 15) = 10612724 a=1 b=4 *(sp + 0) = 134514016 *(sp + 1) = 0 *(sp + 2) = 0 *(sp + 3) = 134513373 *(sp + 4) = 8239384 *(sp + 5) = 134513228 *(sp + 6) = 6 *(sp + 7) = -1076716032 *(sp + 8) = 134513456 *(sp + 9) = 0 *(sp + 10) = -1076715960 *(sp + 11) = 134513799 *(sp + 12) = 1 //value of arg a *(sp + 13) = 4 //value of arg b *(sp + 14) = 134513817 *(sp + 15) = 10612724 Why function arguments are stored from offset 12 of SP? Also notice values at offset 0 to 10 are always same, and value at offset 11 increases by 20 on each invocation of function foo(). -- Manavendra Nath Manav
Why function arguments are stored from offset 12 of SP? Also notice values at offset 0 to 10 are always same, and value at offset 11 increases by 20 on each invocation of function foo().
You have to consider that local variables are allocated on the stack, thus both i, stackptr and sp are allocated on the stack, so if you print all the stack records you will find this variables, then the return pointer, the saved frame pointer (if saved) and then the function parameters. See http://en.wikipedia.org/wiki/Call_stack for a better explanation. If you want to access immediately to the function call parameters you should start from the frame pointer address (if there's one). To play with backtraces you may find useful the backtrace function[1] and libraries like libunwind[2] which take care of this details for you. [1] http://tdistler.com/2008/11/15/how-to-print-a-stack-backtrace-programaticall... [2] http://www.nongnu.org/libunwind/ -- Saluti, Fabio Pozzi
On Wed, Dec 12, 2012 at 3:56 PM, Fabio Pozzi <pozzi.fabio@gmail.com> wrote:
Why function arguments are stored from offset 12 of SP? Also notice values at offset 0 to 10 are always same, and value at offset 11 increases by 20 on each invocation of function foo().
You have to consider that local variables are allocated on the stack, thus both i, stackptr and sp are allocated on the stack, so if you print all the stack records you will find this variables, then the return pointer, the saved frame pointer (if saved) and then the function parameters. See http://en.wikipedia.org/wiki/Call_stack for a better explanation. If you want to access immediately to the function call parameters you should start from the frame pointer address (if there's one). To play with backtraces you may find useful the backtrace function[1] and libraries like libunwind[2] which take care of this details for you.
[1] http://tdistler.com/2008/11/15/how-to-print-a-stack-backtrace-programaticall... [2] http://www.nongnu.org/libunwind/
-- Saluti, Fabio Pozzi
Thanks Fabio, You solved a lot of doubts for me. How to get the frame pointer address? -- Manavendra Nath Manav
On Wed, Dec 12, 2012 at 4:02 PM, Manavendra Nath Manav <mnm.kernel@gmail.com> wrote:
On Wed, Dec 12, 2012 at 3:56 PM, Fabio Pozzi <pozzi.fabio@gmail.com> wrote:
Why function arguments are stored from offset 12 of SP? Also notice values at offset 0 to 10 are always same, and value at offset 11 increases by 20 on each invocation of function foo().
You have to consider that local variables are allocated on the stack, thus both i, stackptr and sp are allocated on the stack, so if you print all the stack records you will find this variables, then the return pointer, the saved frame pointer (if saved) and then the function parameters. See http://en.wikipedia.org/wiki/Call_stack for a better explanation. If you want to access immediately to the function call parameters you should start from the frame pointer address (if there's one). To play with backtraces you may find useful the backtrace function[1] and libraries like libunwind[2] which take care of this details for you.
[1] http://tdistler.com/2008/11/15/how-to-print-a-stack-backtrace-programaticall... [2] http://www.nongnu.org/libunwind/
-- Saluti, Fabio Pozzi
Thanks Fabio, You solved a lot of doubts for me. How to get the frame pointer address?
I found that gcc has in-build function to retrieve frame pointer address void * __builtin_frame_address (unsigned int level) When i call print values at offsets starting from __builtin_frame_address (0) the function arguments start from offset 2. How can I confirm that this behavior is always consistent. -- Manavendra Nath Manav
When i call print values at offsets starting from __builtin_frame_address (0) the function arguments start from offset 2. How can I confirm that this behavior is always consistent.
Arguments are pushed on the stack before the saved frame pointer, thus you have to add an offset equal to the frame pointer address size if you start from the beginning of the saved frame pointer record on the stack. -- Saluti, Fabio Pozzi
On Wed, Dec 12, 2012 at 4:38 PM, Fabio Pozzi <pozzi.fabio@gmail.com> wrote:
When i call print values at offsets starting from __builtin_frame_address (0) the function arguments start from offset 2. How can I confirm that this behavior is always consistent.
Arguments are pushed on the stack before the saved frame pointer, thus you have to add an offset equal to the frame pointer address size if you start from the beginning of the saved frame pointer record on the stack.
Thanks Fabio! If I execute the same code on ARM arch, does it needs any changes? -- Manavendra Nath Manav
On 12/12/2012 12:24 PM, Manavendra Nath Manav wrote:
On Wed, Dec 12, 2012 at 4:38 PM, Fabio Pozzi <pozzi.fabio@gmail.com> wrote:
When i call print values at offsets starting from __builtin_frame_address (0) the function arguments start from offset 2. How can I confirm that this behavior is always consistent.
Arguments are pushed on the stack before the saved frame pointer, thus you have to add an offset equal to the frame pointer address size if you start from the beginning of the saved frame pointer record on the stack.
Thanks Fabio! If I execute the same code on ARM arch, does it needs any changes?
I just wanted to mention. AFAIK who parameters are passed to the called function depends on the architecture (stack or some registers + stack). I vaguely remember some MIPS ASM programming exercises in first year of university... But if gcc has a in built function, that should do on all architectures, though.
在 2012-12-12，19:28，"Manavendra Nath Manav" <mnm.kernel@gmail.com> 写道：
On Wed, Dec 12, 2012 at 4:38 PM, Fabio Pozzi <pozzi.fabio@gmail.com> wrote:
When i call print values at offsets starting from __builtin_frame_address (0) the function arguments start from offset 2. How can I confirm that this behavior is always consistent.
Arguments are pushed on the stack before the saved frame pointer, thus you have to add an offset equal to the frame pointer address size if you start from the beginning of the saved frame pointer record on the stack.
Thanks Fabio! If I execute the same code on ARM arch, does it needs any changes?
Arm does not use stack to pass parameters when parameters are less than 4, it uses registers r0 to r3 to pass parameters, and at the beginning of subroutine, r0 to r3 are not stored on stack. So it is complicated to find out parameters from stack as I know.
-- Manavendra Nath Manav
_______________________________________________ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
participants (4)
-
Fabio Pozzi -
Manavendra Nath Manav -
Matthias Brugger -
卜弋天