Почему панель GCC работает с NOP?

Я работал с C некоторое время и совсем недавно начал разбираться в ASM. Когда я компилирую программу:

int main(void)
  {
  int a = 0;
  a += 1;
  return 0;
  }

В дизассемблере objdump есть код, но после ret нет:

...
08048394 <main>:
 8048394:       55                      push   %ebp
 8048395:       89 e5                   mov    %esp,%ebp
 8048397:       83 ec 10                sub    $0x10,%esp
 804839a:       c7 45 fc 00 00 00 00    movl   $0x0,-0x4(%ebp)
 80483a1:       83 45 fc 01             addl   $0x1,-0x4(%ebp)
 80483a5:       b8 00 00 00 00          mov    $0x0,%eax
 80483aa:       c9                      leave  
 80483ab:       c3                      ret    
 80483ac:       90                      nop
 80483ad:       90                      nop
 80483ae:       90                      nop
 80483af:       90                      nop
...

Из того, что я узнал, nops ничего не делает, и поскольку после ret даже не будет выполняться.

У меня вопрос: зачем беспокоиться? Не может ELF (linux-x86) работать с разделом .text (+ main) любого размера?

Буду признателен за любую помощь, просто пытаюсь учиться.

Во-первых, так gccбывает не всегда. Заполнение контролируется -falign-functions, которое автоматически включается -O2и -O3:

-falign-functions
-falign-functions=n

Выровняйте начало функций со следующей степенью двойки больше чем n, пропуская до nбайтов. Например, -falign-functions=32выравнивает функции по следующей 32-байтовой границе, но -falign-functions=24выравнивает по следующей 32-байтовой границе, только если это можно сделать, пропустив 23 байта или меньше.

-fno-align-functionsи -falign-functions=1эквивалентны и означают, что функции не будут согласованы.

Некоторые ассемблеры поддерживают этот флаг, только когда n является степенью двойки; в этом случае оно округляется.

Если n не указано или равно нулю, используйте машинно-зависимое значение по умолчанию.

Включено на уровнях -O2, -O3.

Для этого может быть несколько причин, но основная из них на x86, вероятно, следующая:

Большинство процессоров выбирают инструкции выровненными блоками по 16 или 32 байта. Может быть полезно выровнять критические записи цикла и записи подпрограммы по 16, чтобы минимизировать количество 16-байтовых границ в коде. В качестве альтернативы, убедитесь, что нет 16-байтовой границы в первых нескольких инструкциях после записи критического цикла или записи подпрограммы.

(Цитата из «Оптимизация подпрограмм на ассемблере» Агнера Фога.)

edit: Вот пример, демонстрирующий заполнение:

// align.c
int f(void) { return 0; }
int g(void) { return 0; }

При компиляции с использованием gcc 4.4.5 с настройками по умолчанию я получаю:

align.o:     file format elf64-x86-64

Disassembly of section .text:

0000000000000000 <f>:
   0:   55                      push   %rbp
   1:   48 89 e5                mov    %rsp,%rbp
   4:   b8 00 00 00 00          mov    $0x0,%eax
   9:   c9                      leaveq 
   a:   c3                      retq   

000000000000000b <g>:
   b:   55                      push   %rbp
   c:   48 89 e5                mov    %rsp,%rbp
   f:   b8 00 00 00 00          mov    $0x0,%eax
  14:   c9                      leaveq 
  15:   c3                      retq   

Уточнение -falign-functionsдает:

align.o:     file format elf64-x86-64

Disassembly of section .text:

0000000000000000 <f>:
   0:   55                      push   %rbp
   1:   48 89 e5                mov    %rsp,%rbp
   4:   b8 00 00 00 00          mov    $0x0,%eax
   9:   c9                      leaveq 
   a:   c3                      retq   
   b:   eb 03                   jmp    10 <g>
   d:   90                      nop
   e:   90                      nop
   f:   90                      nop

0000000000000010 <g>:
  10:   55                      push   %rbp
  11:   48 89 e5                mov    %rsp,%rbp
  14:   b8 00 00 00 00          mov    $0x0,%eax
  19:   c9                      leaveq 
  1a:   c3                      retq   

Это делается для выравнивания следующей функции по границе 8, 16 или 32 байта.

Из «Оптимизация подпрограмм на ассемблере» А.Фога:

11.5 Выравнивание кода

Большинство микропроцессоров выбирают код выровненными блоками по 16 или 32 байта. Если важная запись подпрограммы или метка перехода оказывается ближе к концу 16-байтового блока, тогда микропроцессор получит только несколько полезных байтов кода при выборке этого блока кода. Возможно, ему также придется получить следующие 16 байтов, прежде чем он сможет декодировать первые инструкции после метки. Этого можно избежать, выровняв важные записи подпрограмм и записи цикла по 16.

[...]

Выровнять запись подпрограммы так же просто, как поставить столько NOP, сколько необходимо, перед записью подпрограммы, чтобы адрес делился на 8, 16, 32 или 64, по желанию.

Насколько я помню, инструкции передаются по конвейеру в процессоре, а различные блоки процессора (загрузчик, декодер и т. Д.) Обрабатывают последующие инструкции. Когда RETинструкции выполняются, несколько следующих инструкций уже загружены в конвейер процессора. Это предположение, но вы можете начать копать здесь и, если узнаете (может быть, конкретное количество NOPбезопасных s, поделитесь своими выводами, пожалуйста.