Dlaczego pad GCC działa z NOP?

Pracuję z C przez krótki czas i bardzo niedawno zacząłem zajmować się ASM. Kiedy kompiluję program:

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

Demontaż objdump ma kod, ale nops po 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
...

Z tego, czego się dowiedziałem, nops nic nie robi, a ponieważ po ret nie zostałby nawet stracony.

Moje pytanie brzmi: po co się przejmować? Czy ELF (linux-x86) nie może działać z sekcją .text (+ main) dowolnego rozmiaru?

Byłbym wdzięczny za każdą pomoc, po prostu próbując się nauczyć.

Przede wszystkim gccnie zawsze to robi. Wypełnienie jest kontrolowane przez -falign-functions, które jest automatycznie włączane przez -O2i -O3:

-falign-functions
-falign-functions=n

Wyrównaj początek funkcji do następnej potęgi dwa większej niż n, przeskakując do nbajtów. Na przykład -falign-functions=32wyrównuje funkcje do następnej 32-bajtowej granicy, ale wyrówna -falign-functions=24ją do następnej 32-bajtowej granicy tylko wtedy, gdy można to zrobić, pomijając 23 bajty lub mniej.

-fno-align-functionsi -falign-functions=1są równoważne i oznaczają, że funkcje nie zostaną wyrównane.

Niektóre asemblery obsługują tę flagę tylko wtedy, gdy n jest potęgą dwóch; w takim przypadku jest zaokrąglana w górę.

Jeśli n nie jest określone lub wynosi zero, użyj wartości domyślnej zależnej od komputera.

Włączone na poziomach -O2, -O3.

Może być wiele powodów, dla których warto to zrobić, ale główny na x86 jest prawdopodobnie taki:

Większość procesorów pobiera instrukcje w wyrównanych blokach 16-bajtowych lub 32-bajtowych. Korzystne może być wyrównanie krytycznych wpisów pętli i podprogramów o 16 w celu zminimalizowania liczby 16-bajtowych granic w kodzie. Alternatywnie, upewnij się, że w pierwszych kilku instrukcjach po wejściu w pętli krytycznej lub wpisie podprogramu nie ma granicy 16-bajtowej.

(Cytat z „Optimizing podprogramów w języku asemblera” autorstwa Agner Fog.)

edycja: Oto przykład, który demonstruje dopełnienie:

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

Po skompilowaniu przy użyciu gcc 4.4.5 z domyślnymi ustawieniami otrzymuję:

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   

Określenie -falign-functionsdaje:

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   

Ma to na celu wyrównanie następnej funkcji do granicy 8, 16 lub 32 bajtów.

Z „Optimizing podprogramów w języku asemblera” autorstwa A. Fog:

11.5 Wyrównanie kodu

Większość mikroprocesorów pobiera kod w wyrównanych blokach 16-bajtowych lub 32-bajtowych. Jeśli ważny wpis podprogramu lub etykieta skoku znajduje się blisko końca 16-bajtowego bloku, wówczas mikroprocesor otrzyma tylko kilka użytecznych bajtów kodu podczas pobierania tego bloku kodu. Może być konieczne pobranie kolejnych 16 bajtów, zanim zdekoduje pierwsze instrukcje po etykiecie. Można tego uniknąć, wyrównując ważne wpisy podprogramów i pętli o 16.

[…]

Wyrównanie wpisu podprogramu jest tak proste, jak umieszczenie tylu NOP, ile potrzeba, przed wpisem podprogramu, aby adres był podzielny przez 8, 16, 32 lub 64, zależnie od potrzeb.

O ile pamiętam, instrukcje są przetwarzane potokowo w procesorze i różne bloki procesora (program ładujący, dekoder itp.) Przetwarzają kolejne instrukcje. Kiedy RETinstrukcje są wykonywane, kilka następnych instrukcji jest już ładowanych do potoku procesora. To przypuszczenie, ale możesz zacząć szukać tutaj, a jeśli się dowiesz (może konkretna liczba NOPbezpiecznych, podziel się swoimi odkryciami).