1

I'm attempting to write a function that is called at the end of a recursive invocation of foo(). This function will access the stack frame to display all passed arguments into foo() at the time of each invocation. I am totally confused as to how I can access the stack frame in this manner. Appreciate any insights on the matter, thank you!

Iharob Al Asimi
  • 52,653
  • 6
  • 59
  • 97
prestige13
  • 71
  • 4
  • 1
    Does it have to be portable, proper C? – user253751 Nov 12 '15 at 02:47
  • Not really, I just need to get it working any way I can! – prestige13 Nov 12 '15 at 02:50
  • 1
    [libunwind](http://www.nongnu.org/libunwind/) is one option if you are on Linux. – kaylum Nov 12 '15 at 02:54
  • Wait, actually the C code does need to be portable/proper – prestige13 Nov 12 '15 at 03:00
  • @prestige13: All the better to use libunwind or another dedicated library so as to not mess something up :) – tonysdg Nov 12 '15 at 03:04
  • Or if you can modify the recursive function, you could make your own "stack frames", and keep a linked list of them. – user253751 Nov 12 '15 at 03:08
  • Yes, I second @immibis. Because even if you get access to all the stack frames (via libunwind or otherwise) there is no guarantee that the original function call arguments have been preserved. So OP, you really need to describe the constraints of your problem a bit more. What can and can't be done as part of the solution. – kaylum Nov 12 '15 at 03:12
  • So the goal is to display all the arguments that have been passed recursively at the end of the recursive chain. I need to go back to the start of the stack frame if possible and display all the proceeding stored arguments and local variables. – prestige13 Nov 12 '15 at 03:19
  • I can't use any machine code, only C – prestige13 Nov 12 '15 at 03:19
  • @prestige13 But can you change the way that the recursive function is implemented as suggested by immibis? Or you are not able/allowed to change that function's code? And does it have to be within the running application itself or can you inspect that state from outside the running application? – kaylum Nov 12 '15 at 03:34
  • Oh I see what you're asking! No I can't modify the code within foo() whatsoever. My function "recover()" that I'm writing must do all the heavy lifting, although I am allowed to write additional outside functions that recover() can call – prestige13 Nov 12 '15 at 03:46
  • @prestige13 In that case I don't think what you are trying to do is possible. By the time `recover` is called, the arguments to any or all of the recursive calls could have been lost already. AFAIK, there is no guarantee that the args are there in any of the the stack frames at that point in time. – kaylum Nov 12 '15 at 04:13
  • recover() is called in the last instance of the recursive call. Does this make it possible as I am calling recover while the recursion is still executing? @kaylum – prestige13 Nov 12 '15 at 04:20
  • No, like I said. There is nothing that says the args need to be pushed onto the stack before calling the next function. Only what is needed is saved onto the stack. The args may no longer be needed at that point in time and hence hence they would not be pushed onto the stack. – kaylum Nov 12 '15 at 04:24
  • @kaylum It's probably possible, especially if compiling without optimizations. – user253751 Nov 12 '15 at 05:07
  • @immibis Yes, without optimisations it's probably possible. With optimisations I just don't see how that's possible to do reliably and I would equate that with not possible since it'll be hit and miss depending on the code and the compiler. – kaylum Nov 12 '15 at 05:33
  • @kaylum I discovered the best way to go about this is to create a pointer that points to itself thereby giving me the address of recover in the stack frame void recover () { int * x = (int *)&x; } The only problem is that my program reaches the recover function and skips over it! I've verified this through GDB. Can you see any reason why it would do this? – prestige13 Nov 13 '15 at 01:37
  • Unless you have disabled compiler optimisation it is likely that the compiler has removed that function call altogether as it essentially does nothing observable. Not sure if there is a better way, but you could make `x` a global variable to prevent the compiler optimising out the function call. But even that may not work as the compiler may inline the function (and hence no stack). – kaylum Nov 13 '15 at 01:45
  • Thanks for your help, if I insert a printf statement within the function the program will read the printf statement and output accordingly. But then it will totally skip over the other line. – prestige13 Nov 13 '15 at 01:49
  • Same problem. The compiler can optimise out the whole function but it can also optimise out just those statements that it has determined are not needed. – kaylum Nov 13 '15 at 02:25

0 Answers0