x86_64 calling conventions and stack frames

问题

I am trying to make sense out of the executable code that GCC (4.4.3) is generating for an x86_64 machine running under Ubuntu Linux. In particular, I don't understand how the code keeps track of stack frames. In the old days, in 32-bit code, I was accustomed to seeing this "prologue" in just about every function:

push %ebp
movl %esp, %ebp

Then, at the end of the function, there would come an "epilogue," either

sub $xx, %esp   # Where xx is a number based on GCC's accounting.
pop %ebp
ret

or simply

leave
ret

which accomplishes the same thing:

Set the Stack Pointer to the top of the current frame, just below the return address
Restore the old Frame Pointer value.

In 64-bit code, as I see it through an objdump disassembly, many functions do not follow this convention--they do not push %rbp and then save %rsp to %rbp, How does a debugger like GDB build a backtrace?

My real goal here to is to try to figure out a reasonable address to consider as the top (highest address) of the user stack when execution reaches the start of an arbitrary function further into the program, where perhaps the Stack Pointer has moved down. For the "top," for instance, the original address of argv would be ideal--but I have no access to it from an arbitrary function that main calls. I had at first thought that I could use the old backtrace method: chasing saved Frame Pointer values until the value saved is 0--then, the next one after that can count as the highest practical value. (This is not the same as getting the address of argv, but it will do--say, to find out the Stack Pointer value at _start or whatever _start calls [e.g., __libc_start_main].) Now, I don't know how to get the equivalent address in 64-bit code.

Thanks.

回答1:

I think the difference is that omitting the frame pointer is simply more encouraged in amd64. A footnote on page 16 of the abi says

The conventional use of %rbp as a frame pointer for the stack frame may be avoided by using %rsp (the stack pointer) to index into the stack frame. This technique saves two instructions in the prologue and epilogue and makes one additional general-purpose register (%rbp) available.

I don't know what GDB does. I assume that when compiled with -g, objects have magic debugging information that allows GDB to reconstruct what it needs. I don't think I've tried GDB on a 64-bit machine without debugging info.

回答2:

GDB uses the DWARF CFI for unwinding. For unstripped binaries compiled with -g, this will be in the .debug_info section. For stripped x86-64 binaries, there's unwind info in the .eh_frame section. This is defined in the x86-64 ABI, section 3.7, page 56. Handling this info yourself is pretty hard, since parsing DWARF is very involved, but I believe libunwind contains support for it.

回答3:

If the address of argv is what you want, why not just save a pointer to it in main?
Trying to unwind the stack would be highly unportable, even if you get it to work.
Even if you do manage to go back over the stack, it isn't obvious that the first function's frame pointer would be NULL. The first function on the stack doesn't return, but calls a system call to exit, and therefore its frame pointer is never used. There's no good reason why it would be initialized to NULL.

回答4:

Assuming that I am linking with glibc (which I am doing), it looks as if I can solve this problem for practical purposes with the glibc global symbol __libc_stack_end:

extern void * __libc_stack_end;

void myfunction(void) {
  /* ... */
  off_t stack_hi = (off_t)__libc_stack_end;
  /* ... */
}

来源：https://stackoverflow.com/questions/8625352/x86-64-calling-conventions-and-stack-frames

标签

stack

x86-64

calling-convention

backtrace