Why ther are some many padding/leading nop instructions in my binary code?

Question

The test platform is on Linux 32bit, x86. So basically I wrote a simple C program like this:

void main()
{
        double a = 10.0;
        printf("hello world %f\n", a);

}

I use gcc to compile to into ELF binary, and use objdump to disassemble it. I solve the reference to .rodata section, and refine the asm code in this :

extern  printf
section .rodata

S_80484d0   db 0x68
db 0x65
  db 0x6c
db 0x6c
db 0x6f
db 0x20
db 0x77
db 0x6f
db 0x72
db 0x6c
db 0x64
db 0x20
db 0x25
db 0x66
db 0x0a


S_80484f0 db 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x24, 0x40

section .text
global main
main:
push   ebp
mov    ebp,esp
and    esp,0xfffffff0
sub    esp,0x20
fld    qword [S_80484f0]
fstp   QWORD [esp+0x18]
fld    QWORD [esp+0x18]
fstp   QWORD [esp+0x4] 
mov    DWORD [esp],S_80484d0
call   printf
leave
ret

Then I re-compile this asm code to get a new ELF binary, and comparing the .text section of these two binaries.

Here is the confusing thing: The only different I can find is that there are more leading nop in front of the main function like this:

new ELF binary leading nop:

new ELF binary ending nop:

old ELF binary:

Basically I don't think it is kinda of "alignment" issue, because there are just too much nop.

What's more, when I change the original code into just a simple helloworld code(without double number a), then basically there is no difference between these two ELF binaries.

Could anyone give me some help on why there are so many nop generated?

Thank you

Answer 1

Alignment.

Note that all of the NOPs end (and the next function begins) at ...C0, ...F0. The compiler and/or linker inserted padding bytes so that the functions begin at 0x10 aligned addresses.

Different compilers / linkers will use different values for these bytes. I've seen 90 (nop), CC (int3), as well as multi-byte NOPs that exactly fill the space between the functions.

You should check out this great answer on the same question over at Stack Overflow.

In short, this is done for performance reasons, as processors typically fetch instructions in 16- or 32-byte strides, so it makes sense to have functions begin at one of these boundaries.