Programs – Calling Conventions CS/COE 0449 (term 2174) Jarrett Billingsley

Class announcements Hi ;B We're gonna go down the rabbit hole today. Stay with me. This stuff will be really useful to know for project 2. 2/16/2017 CS/COE 0449 term 2174

Review question time 2/16/2017 CS/COE 0449 term 2174

Calling Conventions 2/16/2017 CS/COE 0449 term 2174

So I just met you I'm sorry We talked about the stack, how it's used to support function calls. When you call a function, we push an AR onto the stack. When it returns, its AR is popped. Remember what's in the AR? But what about the rest of the machinery? How do those parameters get in there? How does the stack pointer get moved around? How are values returned from the function? What responsibilities/protocols do functions have to follow to "play nice" with other code and with the OS? These and other questions are covered by calling conventions. 2/16/2017 CS/COE 0449 term 2174

Like I said at the beginning... Our CPUs today are made to run C programs quickly. So naturally, they have built-in mechanisms to call and return from functions. Call instructions save the return address – the address of the instruction after the call – somewhere. Then they jump to the function being called. MIPS puts the return address in the $ra register. x86 pushes the return address onto the stack. Return instructions do the opposite. MIPS just uses "jump to register" to jump to the return address. x86 pops it off the stack, then jumps to it. MIPS x86 jal name call name jr $ra ret 2/16/2017 CS/COE 0449 term 2174

Passing parameters Here's where things get really wild. How did you pass parameters into functions in MIPS? The $ax registers. But there are only 4. What if you have more than 4 params? The stack! x86-32 is............................................... ;)))))))))) Registers: eax, ebx, ecx, edx, esi, edi, ebp, esp ebp and esp are used for the stack and ARs (we'll see) So we have a whole six registers to use!!! How generous Over the years, MANY, MANY parameter passing conventions have arisen. Let's just look at one of the most common ones: cdecl. 2/16/2017 CS/COE 0449 term 2174

Parameter passing with cdecl In cdecl, all parameters are pushed onto the stack, but in reverse order: the last parameter is pushed first. No really – it makes sense! What direction does the stack grow? If we call f(1, 2, 3), A cdecl function call might look like either of these: Stack 3 2 1 esp This would be like: sw 3, 8($sp) push 3 push 2 push 1 call f sub esp, 16 mov [esp+8], 3 mov [esp+4], 2 mov [esp], 1 2/16/2017 CS/COE 0449 term 2174

Peeking under the hood First let's write a little program to call a function. Now let's compile it, using these options: -g includes debugging info in the executable. This makes it easier to debug the program in gdb. -m32 compiles to 32-bit x86. If we leave this off we get x64 which EHGHHHCHA AAAAAAHHHHHHHHH Now let's run it, break at main, and disas...... Oh god. Oh no. OH GOD. This looks horrible. Let's make a file called ~/.gdbinit ~ is short for your home directory (the directory you start in). .gdbinit is sort of a settings file for gdb. In it, let's write set disassembly-flavor intel Save, and try again... 2/16/2017 CS/COE 0449 term 2174

Peeking under the much easier-to-read hood Now let's see how main calls f with disas /m! The /m option will only show the C source if it's available. Won't work on your project ;))))))))))) Now let's look inside f to see how it computes its return value. Notice when it accesses the arguments, it uses [ebp+offs]. What the heck is ebp? And why is the first argument at offset 8 instead of 0? 2/16/2017 CS/COE 0449 term 2174

The stack frame register and { } esp is the stack pointer. It marks the end of the AR. ebp – "base pointer" – marks the beginning* of the AR. When we first came into f, the call instruction just pushed the return address, so the stack looks like: Then we have this weird sequence that { does: push ebp mov ebp, esp The push saves the old value of ebp. The mov makes ebp point to that old ebp. And now.... uh........ um.......... what did that do? Stack 3 2 1 return esp old ebp ebp 2/16/2017 CS/COE 0449 term 2174

pop ebp leave ret It's a linked list of ARs! Stack ??? _init's AR ebp is the pointer to the head of a linked list. Every AR stores a pointer to the end of the AR of the function that called it. When the function is about to return, it does pop ebp This moves ebp back up to where it was before this function was called! If we put a local variable in f we'll see this: leave ret wha... Stack ??? _init's AR _init's ebp main's AR main's ebp f's AR f's ebp printf's AR ebp 2/16/2017 CS/COE 0449 term 2174

push ebp mov ebp, esp mov esp, ebp pop ebp The leave instruction When we entered the function, we did: push ebp mov ebp, esp The x86 leave instruction is functionally identical to: mov esp, ebp pop ebp Which is the inverse. It moves both esp and ebp back to where they were when the function started. There is an enter instruction as well, which does the same thing as the push-mov on entry. x86 is full of silly instructions. Why did the compiler use leave but not enter? ¯\_(ツ)_/¯ 2/16/2017 CS/COE 0449 term 2174

Space for locals When we added a local to f, you'll notice the stuff at the beginning of the function – the prologue – changed a bit. Now there's an instruction that moves esp down (sub esp, 0x10). This is allocating space for the local variables! It's allocating 16 bytes for alignment reasons. (modern versions of x86 like the stack to be aligned like this. caches. SSE. etc.) Notice in the code, it refers to arguments with [ebp+offs] and the local variable with [ebp-offs]. Something to keep in mind... Locals could also be accessed with [esp+offs]. Sometimes it does it, sometimes it doesn't! I don't really know why! 2/16/2017 CS/COE 0449 term 2174

Returning Notice what the return statement assembles to. It puts a value in eax. This is the convention in cdecl. What if the value is bigger than 4 bytes? What if it's a float SHHHH shhhhhhhhhh you don't wanna know shhhhhhhhhhhhhhhhh Then the function epilogue which we saw before moves the ebp pointer back to where they were when the function started, before returning. 2/16/2017 CS/COE 0449 term 2174

Loose ends Let's look at the stack, esp, and ebp through this whole process: In main, about to call f. In f, after the prologue. Just did ret, back in main. Just got into f. Stack old ebp Stack old ebp 3 2 1 ret. addr Stack old ebp 3 2 1 ret. addr main ebp Stack old ebp 3 2 1 ebp ebp ebp esp Uhh, is anyone gonna clean up this mess?? esp esp ebp esp 2/16/2017 CS/COE 0449 term 2174

Who cleans the stack? In cdecl it is the responsibility of the caller to put esp back to where it was before the call. (the compiler is being clever in main and relying on leave to clean up those arguments still sitting on the stack.) Why? In MIPS you did addi $sp, $sp, 24 before returning and it was great. Well, there ARE x86 calling conventions where the callee cleans, such as stdcall on windows. But C has this really weird feature that cdecl was created to support... Variadic functions. 2/16/2017 CS/COE 0449 term 2174

printf is very confused Have you every really looked at the docs for printf? int printf(const char* format, ...); So there's an argument and then... maybe it's just being cryptic... Let's see what a call to printf looks like. So how does printf know, exactly, how many things you passed it? It... doesn't. The only information printf has about the parameters is the format string you give it as the first parameter. This is why the caller is responsible for cleaning the stack: because the callee has no idea how many parameters it was passed. This is why you can call functions without prototyping them first and they still "work." The caller knows how to clean up! 2/16/2017 CS/COE 0449 term 2174

Being a good roommate One last thing to consider: register use. When main calls f, it might assume that some registers are unchanged. (For example, ebp and esp!) MIPS has a nice neat protocol: callee saves $sx registers before using them, and restores them before returning. In x86-32, ebx, edi, and esi should be saved and restored by the callee in the same way. ebp and esp are also saved and restored, in a different way. This means eax, ecx, and edx are free to be changed without saving them. You'll see these registers used for temporary values alllllllllll the time. 2/16/2017 CS/COE 0449 term 2174

WHYYYYYY???????? Why does all this stuff matter? Everything your computer does is based on every function following this honor system. isn't that reassuring :^) If anyone messes up the convention, you get a crash. Even if you, the programmer, aren't writing assembly, the compiler has to. The compiler has to know how to call functions. 2/16/2017 CS/COE 0449 term 2174