Why does GCC pad functions with NOPs?

Question

I've been working with C for a short while and very recently started to get into ASM. When I compile a program:

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

The objdump disassembly has the code, but nops after the 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
...

From what I learned nops do nothing, and since after ret wouldn't even be executed.

My question is: why bother? Couldn't ELF(linux-x86) work with a .text section(+main) of any size?

I'd appreciate any help, just trying to learn.

Do those NOPs keep going? If they stop at `80483af`, then maybe it's padding to align the next function to 8 or 16 bytes. — Mysticial, Oct 27 '11 at 06:51
no after the 4 nops it goes strait to a function: __libc_csu_fini — olly, Oct 27 '11 at 06:55
If the NOPs were inserted by gcc then I don't think it'll use only 0x90 since there are many NOPs with size variable from [1-9 bytes](http://software.intel.com/en-us/forums/topic/307174) (10 if use [gas syntax](http://stackoverflow.com/a/12564044/995714)) — phuclv, Feb 10 '14 at 03:35

NPE · Accepted Answer · 2011-10-27T20:15:17.527

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 assembly language" by Agner Fog.)

edit: Here is an example that demonstrates the padding:

// align.c
int 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-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

Specifying -falign-functions gives:

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

@olly: I've tested it with gcc 4.4.5 on 64-bit Ubuntu and in my tests there's no padding by default, and there is padding with `-falign-functions`. — NPE, Oct 27 '11 at 07:13
@aix: I'm on centOS 6.0(32-bit) and without any flags have the padding. Anyone want me to dump my full "objdump -j .text -d ./test" output? — olly, Oct 27 '11 at 07:17
On further testing, when I compile it as an object: "gcc -c test.c". There is no padding, but when I link: "gcc -o test test.o" it appears. — olly, Oct 27 '11 at 07:42
@olly: That padding is inserted by the linker, to satisfy the alignment requirements of the function that follows `main` in the executable (in my case that function is `__libc_csu_fini`). — NPE, Oct 27 '11 at 09:54
@NPE Could you please look at [Why does gcc generate 15-20% faster code if I optimize for SIZE instead of speed?](http://stackoverflow.com/q/19470873/341970) Based on your answer here, I believe you would be able to answer my question as well. Many thanks! — Ali, Oct 20 '13 at 15:27

score 15 · Answer 2 · edited Jun 20 '20 at 09:12

15

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 many NOP 's as needed before thesubroutine entry to make the address divisible by 8, 16, 32 or 64, as desired.

edited Jun 20 '20 at 09:12

Community

1
1

answered Oct 27 '11 at 06:53

hamstergene

24,039
5
57
72

It's the difference between 25-29 bytes(for main), are you talking of something greater? Like the text section, through readelf I found it to be 364 bytes? I also noticed 14 nops on _start. Why doesn't "as" do these things? I am rookie, apologies. – olly Oct 27 '11 at 07:02
@olly: I've seen development systems that perform whole-program optimization on compiled machine code. If the address of function `foo` is 0x1234, then code which happens to use that address in close proximity to a literal 0x1234 might end up generating machine code like `mov ax,0x1234 / push ax / mov ax,0x1234 / push ax` which the optimizer could then replace with `mov ax,0x1234 / push ax / push ax`. Note that functions must not be relocated after such optimization, so the elimination of instructions would improve execution speed, but not code size. – supercat Jul 30 '15 at 18:30

mco · Answer 3 · 2011-10-27T06:54:07.777

5

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.

edited Oct 27 '11 at 06:54

answered Oct 27 '11 at 06:44

mco

159
1
7

@ninjalj: Huh? This question is asking about x86, which is pipelined (as mco said). Many modern x86 processors also speculatively execute instructions that "shouldn't" be executed, perhaps including these nops. Perhaps you meant to comment elsewhere? – David Cary Oct 06 '13 at 21:07
3

@DavidCary: in x86, that is totally transparent to the programmer. Wrongly-guessed speculatively executed instructions just have their results and effects discarded. On MIPS, there is no "speculative"-part at all, the instruction in a branch delay slot is always executed, and the programmer has to fill the delay slots (or let the assembler do it, which would probably result in `nop`s). – ninjalj Oct 06 '13 at 21:27
@ninjalj: Yes, the effect of wrongly-guessed speculatively executed ops and non-aligned instructions are transparent, in the sense that they have no effect on the output data values. However, they both have an effect on the timing of the program, which may be the reason gcc adds nops to x86 code, which is what the original question asked. – David Cary Oct 07 '13 at 18:35
1

@DavidCary: if that was the reason, you would only see it after conditional jumps, not after an unconditional `ret`. – ninjalj Oct 07 '13 at 19:25
2

This isn't why. An indirect jump's fallback prediction (on a BTB miss) is the next instruction, but if that's non-instruction garbage the recommended optimization to stop mis-speculation is an instructions like `ud2` or `int3` that always faults, so the front-end knows to stop decoding instead of feeding a potentially expensive `div` or spurious TLB-miss load into the pipeline for example. This isn't needed after a `ret` or direct `jmp` tailcall at the end of a function. – Peter Cordes Jan 06 '20 at 00:04

Why does GCC pad functions with NOPs?

3 Answers3

Linked

Related