Dlaczego poduszki GCC działają z NOPami?

Question

Pracuję z C przez krótki czas i bardzo niedawno zacząłem wchodzić w ASM. Kiedy skompilować program:

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

objdump demontaż 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 co dowiedziałem NoPS nic nie robić, a ponieważ po ret nie byłoby nawet wykonany.

Moje pytanie brzmi: po co? Czy ELF (linux-x86) nie mógł pracować z sekcją .text (+ main) o dowolnym rozmiarze?

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

Answer 1

Po pierwsze, gcc nie zawsze to robi. Wyściółka jest kontrolowana przez -falign-functions, która jest automatycznie włączona -O2 i -O3:

-falign-functions
-falign-functions=n

wyrównać początek funkcji do następnej power-of-two większa niż n, omijając w górę do n bajtów. Na przykład: -falign-functions=32 wyrównuje funkcje do następnej granicy 32-bajtowej, ale -falign-functions=24 zostanie wyrównane do następnej granicy 32-bajtowej tylko , jeśli można to zrobić, pomijając 23 bajty lub mniej.

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

Niektóre asemblery obsługują tę flagę, gdy n jest potęgą dwóch; w tym przypadku jest on zaokrąglany w górę.

Jeśli n nie jest określone lub wynosi zero, użyj domyślnego ustawienia zależnego od urządzenia.

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

Nie może być wiele powodów ku temu, ale głównym z nich na x86 jest prawdopodobnie to:

Większość procesorów pobrać instrukcje w wyrównanych 16-bajtowych lub 32-bajtowych bloków. Może to być korzystne dla wyrównania krytycznych pozycji pętli i wpisów podprogramów przez 16, aby zminimalizować liczbę 16-bajtowych granic w kodzie. Alternatywnie, upewnij się, że nie ma granicy 16 bajtów w pierwszych kilku instrukcjach po wejściu krytycznej pętli lub wpisie podprogramu.

(Cytat z "Optymalizacja podprogramów w montażu języka" przez Agner Fog).

edit: Oto przykład, który pokazuje padding:

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

Kiedy skompilowany przy użyciu gcc 4.4.5 z ustawieniami domyślnymi 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 

Podanie -falign-functions podaje:

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 

Answer 2

O ile pamiętam, instrukcje są przesyłane potokowo w procesorze i różne bloki procesora (program ładujący, dekoder itp.) Przetwarzają kolejne instrukcje. Kiedy wykonywane są instrukcje RET, kilka następnych instrukcji jest już załadowanych do potoku procesora. Zgadnij, ale możesz zacząć kopać tutaj i jeśli się dowiesz (być może konkretny numer NOP s, który jest bezpieczny, podziel się swoimi odkryciami,

Answer 3

Czynności te mają na celu wyrównanie następnej funkcji o 8, 16 lub 32 -bajtowych granica

od „Optymalizacja podprogramów w języku asemblera” przez A.Fog.

11,5 Dostosowanie kodu

Większość mikroprocesory pobrać kod w wyrównanych 16-bajtowych lub 32-bajtowych bloków. Jeśli znacznik wejścia lub skoku importantuboutine jest blisko koniec bloku 16-bajtowego, wtedy procesor pobiera tylko kilka użytecznych bajtów kodu podczas pobierania tego bloku kodu. Może on również pobrać następne 16 bajtów, zanim zdoła odkodować pierwsze instrukcje po thelabel. Można tego uniknąć przez dostosowanie ważne dane podprogramów i wpisy pętlę 16.

[...]

Wyrównywanie pozycję podprogram jest proste wprowadzenie aż NOP jest w razie potrzeby przed wejściem do thesubroutine uczynić adres podzielny przez 8, 16, 32 lub 64, zgodnie z potrzebami.