C在调用函数激活记录时究竟将其实际使用多少堆栈空间？

Question

Environment：gcc version 6.3.0 (MinGW.org GCC-6.3.0-1) on Windows10

I compile and run code in command line.

Here is my code:

#include <stdio.h>  
int func(void){
    int c;
    printf("stack top in func \t%p\n", &c);
    return 1;
}
void main(void)  { 
    int arr[0];
    int i;  
    printf("stack top before func \t%p\n", &i);
    i = func();
    int j;
    printf("stack top after func \t%p\n", &j);
    return;  
}

Here is result:

stack top before func   0061FF2C
stack top in func       0061FEFC
stack top after func    0061FF28

The gap size between the stack top while in function and stack top out of function is 48 bytes.

I then changed the size of "arr" to 1 and the result is:

stack top before func   0061FF28
stack top in func       0061FEFC
stack top after func    0061FF24

The gap just shrinked and the stack top while in function stayed put.The gap size is now 44 bytes.

It stops shrinking when the size of "arr" is 3.

The new gap size is 52 bytes.

Is that sort of strategy of memory management?

What's the benefit when it can use 44 bytes while it chose to use 52 bytes and the size of variables before function call can be known while compile time?

Answer 1

I think you are making some unfounded assumptions on how the stack, and the compiler, work. Namely:

1. that variables are allocated at the moment you declare them,
2. that the "last" variable takes up the "top" of the stack,
3. that the variables only take as much space as they need,
4. that this has a clear and deterministic answer.

Here's a rough idea of what happens when you call a function in C, gcc, x86 platform, no optimizations:

1. The parameters (if any) are stored in registers and/or the stack. The details are different between 32 and 64 bit, integers/pointers, floats, and structs of different sizes, number of arguments, vararg, and more.
2. The call instruction is taken, which pushes the return address onto the stack (taking up 8 bytes in both 32 and 64 bit, I think, though for different reasons) and redirects the processor to the new address.
3. The stack pointer is saved in the BP register, after pushing the original value of BP (4 or 8 bytes).
4. The stack pointer is decremented by enough bytes to accommodate all local variables.

Upon returning,

5. The value of the BP register overwrites the stack pointer, negating step 4 automatically. Then the original value of BP is popped.
6. The ret instruction is taken, popping the return address and jumping there.

It should be noted that this is by no means universal, or guaranteed. "Simple" functions may be optimized to skip steps 3, 4 and 5. Step 4 can in principle happen multiple times. Additional magic can be done to the stack pointer like aligning it to a particular power-of-two boundary (like multiples of 128 for SSE instruction operands), allocating something called the red zone, alloca function, etc. Many exceptions and special cases exist. More details will depend on gcc command line parameters, or their built-in defaults per distribution. Other compilers may follow slightly different, yet compatible, conventions. But let's stick to this model.

What's important to notice is that all the local variables are often allocated all together in step 4, and the size that's taken may be either the total size required or more. For example, it may be mandated by the conventions that the compiler makes sure that the stack pointer is a multiple of 16 at any point (so that the functions themselves can rely on this), in which case it rounds up to the nearest multiple (also with regard to what had been taken in steps 1 through 3). Within this zone the locals are assigned addresses (offset from the BP or SP) such as to respect their size and alignment requirements.

Your example, especially the code in main , can not work because the compiler won't follow your wish to allocate the space for j only after returning from f . It happens along with arr and i in the beginning of the function and the order of the variables is unspecified, likely chosen so that they can be best "packed" into the space that's available, with ints taking addresses at 32- or 64-bit boundaries. Even if it did, the calculation would be mistaken by taking the address of j as the "stack top after func": at best, it would be "stack top after func and allocation ". In general, the "stack top after func" must be the same as the "stack top before func" in the C calling convention.

---

In order to get a more concrete idea in your function, I would suggest either:

Studying the assembly after compilation. The tool at godbolt.com is great for this: here's your code compiled by gcc 8.2 in x86-64 as shown there.

The stack pointer should be reduced by 16 (line 6) plus 8 (the size of RBP @ line 4) plus whatever the call at line 28 required to store the return address, 8 in 64-bit mode.

Using a debugger :

(gdb) b 11
(gdb) b 4
(gdb) run
Starting program: [redacted]
stack top before func   0x7fffffffd2dc

Breakpoint 1, main () at a.c:11
11      i = func();
(gdb) print $rsp
$1 = (void *) 0x7fffffffd2d0
(gdb) c
Continuing.

Breakpoint 2, func () at a.c:4
4       printf("stack top in func \t%p\n", &c);
(gdb) print $rsp
$2 = (void *) 0x7fffffffd2b0

You can see here that rsp reduced by 0x20 == 32.

Answer 2

It is because gcc's stack alignment.

In gcc stack alignment is 16 bytes by default,while,at least in my emvironment. I changed it to 4 bytes with compile option "-mpreferred-stack-boundary=2",just as same as size of int.

Then the stack top in function will move every single time I declare a new int.

Thanks for Jabberwocky and Korni 's comments which introduced a new area I didn't know before.