Why does GCC pad functions with NOPs?

First of all, gcc doesn't always do this. The padding is controlled by -falign-functions, which is automatically turned on by -O2 and -O3:

-falign-functions
-falign-functions=n

Align the start of functions to the next power-of-two greater than n, skipping up to n bytes. For instance, -falign-functions=32 aligns functions to the next 32-byte boundary, but -falign-functions=24 would align to the next 32-byte boundary only if this can be done by skipping 23 bytes or less.

-fno-align-functions and -falign-functions=1 are equivalent and mean that functions will not be aligned.

Some assemblers only support this flag when n is a power of two; in that case, it is rounded up.

If n is not specified or is zero, use a machine-dependent default.

Enabled at levels -O2, -O3.

There could be multiple reasons for doing this, but the main one on x86 is probably this:

Most processors fetch instructions in aligned 16-byte or 32-byte blocks. It can be advantageous to align critical loop entries and subroutine entries by 16 in order to minimize the number of 16-byte boundaries in the code. Alternatively, make sure that there is no 16-byte boundary in the first few instructions after a critical loop entry or subroutine entry.

(Quoted from "Optimizing subroutines in assemblylanguage" by Agner Fog.)

edit: Here is an example that demonstrates the padding:

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

When compiled using gcc 4.4.5 with default settings, I get:

align.o:     file format elf64-x86-64Disassembly 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   

Specifying -falign-functions gives:

align.o:     file format elf64-x86-64Disassembly 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                      nop0000000000000010 <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   

This is done to align the next function by 8, 16 or 32-byte boundary.

From “Optimizing subroutines in assembly language” by A.Fog:

11.5 Alignment of code

Most microprocessors fetch code in aligned 16-byte or 32-byte blocks. If an importantsubroutine entry or jump label happens to be near the end of a 16-byte block then themicroprocessor will only get a few useful bytes of code when fetching that block of code. Itmay have to fetch the next 16 bytes too before it can decode the first instructions after thelabel. This can be avoided by aligning important subroutine entries and loop entries by 16.

[...]

Aligning a subroutine entry is as simple as putting as manyNOP's as needed before thesubroutine entry to make the address divisible by 8, 16, 32 or 64, as desired.

As far as I remember, instructions are pipelined in cpu and different cpu blocks (loader, decoder and such) process subsequent instructions. When RET instructions is being executed, few next instructions are already loaded into cpu pipeline. It's a guess, but you can start digging here and if you find out (maybe the specific number of NOPs that are safe, share your findings please.