I was under the impression that the frame pointer $fp is set to the first word of stack according to
int func(int g) {
int f = 9;
return g f;
}
mips gcc 12.2.0 generated assembly code.
func:
addiu $sp,$sp,-24
sw $fp,20($sp)
move $fp,$sp
sw $4,24($fp)
li $2,9 # 0x9
sw $2,8($fp)
lw $3,24($fp)
lw $2,8($fp)
nop
addu $2,$3,$2
move $sp,$fp
lw $fp,20($sp)
addiu $sp,$sp,24
jr $31
nop
Is it valid that $fp (frame pointer) and $sp (stack pointer) contain the same address? I would have thought $fp would point to the first word on the stack i.e
func:
addiu $sp,$sp,-24
sw $fp,20($sp)
addiu $fp,$sp,20 #let $fp point to the first word on the stack
Are there any rules on which part of the stack $fp should point to or is it all dependent on the descretion of the software developer/compiler?
CodePudding user response:
GCC seems to follow the ABI linked in this answer.
That ABI mandates:
The stack pointer must be adjusted to allocate the stack frame before any other use of the stack pointer register.
A function allocates a stack frame by subtracting the size of the stack frame from $sp on entry to the function. This $sp adjustment must occur before $sp is used within the function and prior to any jump or branch instructions.
So it's not possible to implement the frame pointer as depicted in the book, which would require a move $fp, $sp
and then an addiu $sp, $sp, XX
.
So the code generated by GCC (without optimizations) according to this ABI has an fp
below the frame.
The ABI also mandates a homing/shadow area: even though the first four args are not passed on the stack, the caller must always reserve the corresponding space on the stack so that the callee can save the arg registers on that space.
You can see this behavior by looking at the instruction sw $4,24($fp)
and noting that $fp 24 = original $sp = just above the allocated frame
.
This means that even non-leaf functions (functions that call other functions) will generally have $sp
= $fp
because the compiler knows how much space it needs.
But you can create cases where this is not true, for example by using the infamous alloca
:
#include <alloca.h>
int bar(int, int, int, int, int);
int func(int g) {
int f = 9;
void* h = alloca(g);
return bar(f, f, f, f, f);
}
This code is compiled (without optimizations) to:
func:
addiu $sp,$sp,-48 #Reserve space for the frame
sw $31,44($sp) #Save ra in the highest slot
sw $fp,40($sp) #Save fp in the slow below
move $fp,$sp #Set the frame pointer
sw $4,48($fp) #Spill the first arg (g) in the homing space
li $2,9
sw $2,32($fp) #f = 9
lw $2,48($fp) #g
nop
addiu $2,$2,7
srl $2,$2,3
sll $2,$2,3 #(g 7) / 8 * 8 = g aligned on a multiple of 8 (required by the ABI)
subu $sp,$sp,$2 #alloc g (aligned) bytes on the stack
addiu $2,$sp,24 #Make a pointer 24 bytes ABOVE the new stack pointer
#So there still are 16 byte (homing space) 4 byte (5th arg to bar) 4 bytes (alignment)
#free just above the stack pointer
#Note: we can steal this space from the g bytes allocated because there was a corresponding
#space in the frame initially allocated
addiu $2,$2,7
srl $2,$2,3
sll $2,$2,3 #Align this pointer to 8 bytes
sw $2,36($fp) #h = that pointer
lw $2,32($fp) #f
nop
sw $2,16($sp) #Note f is stored relative to SP
lw $7,32($fp)
lw $6,32($fp)
lw $5,32($fp)
lw $4,32($fp) #args
jal bar #call bar
nop
move $sp,$fp #Restore the stack pointer just below the frame
lw $31,44($sp)
lw $fp,40($sp) #Restore the regs
addiu $sp,$sp,48 #Restore the stack pointer
jr $31
nop
It may be worth drawing the state of the stack to better understand what's going on.
In general, the frame handling strategy used by the compilers will vary with time and you must take what's written in books with a grain of salt because nobody has the time or possibility to update and republish a book each time a new version of a compiler is released.
Just be sure to understand how the examples in the book work and you'll be able to adapt to new conventions pretty easily.