stackframe

I read that when a function call is made by a program, the called function must know how to return to its caller. My question is: How does the called function know how to return to its caller? Is there a mechanism working behind the scenes through the compiler? The compiler obeys a particular "calling convention", defined as part of the ABI you're targeting. That calling convention will include a way for the system to know what address to return to. The calling convention usually takes advantage of the hardware's support for procedure calls. On Intel, for example, the return address is pushed

Way to get the Frame Pointer On a Demo App running on iPhone 5s Device / Xcode 7, I tried to get the frame pointer of an arbitrary thread using thread_get_state , but always result in an incorrect one : - (BOOL)fillThreadState:(thread_t)thread intoMachineContext:(_STRUCT_MCONTEXT *)machineContext { mach_msg_type_number_t state_count = MACHINE_THREAD_STATE_COUNT; kern_return_t kr = thread_get_state(thread, MACHINE_THREAD_STATE, (thread_state_t)&machineContext->__ss, &state_count); if (kr != KERN_SUCCESS) { char *str = mach_error_string(kr); printf("%s\n", str); return NO; } return YES; } I read

The Smalltalk object thisContext look strange and marvelous. I can't understand what it is and how it works. And even how it enables continuations. For C's call-stack, I can easily imagine how is it implemented and working. But for this... I can't. Please help me to understand it. I think it is not an easy question. The stack is reified in the image with instances of MethodContext. A MethodContext can have a sender, which is another MethodContext. That one can have another one...generating a whole stack. MethodContext are instantiated by the VM while executing CompiledMethod (which are also

As was advised long time ago, I always build my release executables without frame pointers (which is the default if you compile with /Ox). However, now I read in the paper http://research.microsoft.com/apps/pubs/default.aspx?id=81176 , that frame pointers don't have much of an effect on performance. So optimizing it fully (using /Ox) or optimizing it fully with frame pointers (using /Ox /Oy-) doesn't really make a difference on peformance. Microsoft seems to indicate that adding frame pointers (/Oy-) makes debugging easier, but is this really the case? I did some experiments and noticed that:

I have a few questions about ebp, esp and stack frame in following code. Why did we substract 28 from esp ? We have two local variables x and y in main. So why didn't we substract 8? And don't we put values to stack from right to left? So why did we add 1 to [eax+8] instead of [eax+4] ? I am a little bit confuse about this structure. Can you help me out? Thx. func(int a, int b, int c) { return a+b+c; } main() { int x, y=3; x=func(y,2,1); } The stack pointer is subtracted by 28 because you need 8 bytes for your two local variables and 12 bytes for the parameters to func. The extra 8 bytes are

As part of answering another question, I wanted to show that the insane level of optimisation of gcc ( -O3 ) would basically strip out any variables that weren't used in main. The code was: #include <stdio.h> int main (void) { char bing[71]; int x = 7; bing[0] = 11; return 0; } and the gcc -O3 output was: .file "qq.c" .text .p2align 4,,15 .globl main .type main, @function main: pushl %ebp xorl %eax, %eax movl %esp, %ebp popl %ebp ret .size main, .-main .ident "GCC: (Ubuntu 4.4.3-4ubuntu5) 4.4.3" .section .note.GNU-stack,"",@progbits Now I can see it's removed the local variables but there's

When using reflection it is possible to obtain the call stack (apart from that it can be a crude approximation due to JIT optimizations) using System.Diagnostics.StackTrace and examine the StackFrame objects contained. How can I get a reference to the object (the this-pointer) on which a method in a stack frame is executing? I know I can get the MethodBase by calling GetMethod() on the stack frame object, but what I'm looking for is something along the lines of GetObject() (which'd naturally return null if the method is static). It seems like the stack frame object can only be queried for