Язык ассемблера, выделяющий память в стеке

Question

#define NORMAL_BUFFER_SIZE 32 
int getbuf() 
{ 
    char buf[NORMAL_BUFFER_SIZE]; 
    Gets(buf); 
    return 1; 
} 

У меня есть код C, подобный этому, и он должен выделить 32 байта в стеке.

Когда я разобрать его,

0804919e <getbuf>: 
804919e: 55      push %ebp 
804919f: 89 e5     mov %esp,%ebp 
80491a1: 83 ec 38    sub $0x38,%esp 
80491a4: 8d 45 d8    lea -0x28(%ebp),%eax 
80491a7: 89 04 24    mov %eax,(%esp) 
80491aa: e8 ef f9 ff ff   call 8048b9e <Gets> 
80491af: b8 01 00 00 00   mov $0x1,%eax 
80491b4: c9      leave 
80491b5: c3      ret  
80491b6: 90      nop 
80491b7: 90      nop 

я получаю что-то вроде этого, я могу видеть, что он выделяет $ 0x38 байт в стек первым, и передать ЬиЕ к Гец, поскольку ЬиЕ является массивом, то передавая базовый указатель на Gets. buf имеют размер 32 байта, то есть 0x20 в шестнадцатеричном формате, , так почему он не передает lea -x020 (% ebp),% eax?

Как я знаю структуру стека должно быть что-то вроде этого

-------------- 
ret addr 
-------------- 
old ebp 
-------------- 
32 bytes for 
buf 
-------------- 
something else 
here 
-------------- 

Answer 1

Структура кадра стека является деталью реализации. Стандарт языка C не предусматривает этого. Таким образом, это может быть что угодно, если существуют локальные переменные. Никто никогда не обещал, что кадр будет содержать ваши локальные переменные и ничего больше.

В этом случае у вас есть неиспользованный 8-байтовый фрагмент между сохраненным EPB и buf, а еще один фрагмент ниже buf. Зачем? Только компилятор знает. Возможно, в сборках отладки есть куки-файлы для защиты стека, но компилятор хочет сохранить соответствие фрейма стека между сборками отладки и выпуска. Возможно, есть требование выравнивания/дополнения, которое важно для некоторых сценариев, которые не отображаются в вашей функции.