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  printfsection .rodataS_80484d0   db 0x68db 0x65  db 0x6cdb 0x6cdb 0x6fdb 0x20db 0x77db 0x6fdb 0x72db 0x6cdb 0x64db 0x20db 0x25db 0x66db 0x0aS_80484f0 db 0x00, 0x00, 0x00, 0x00, 0x00, 0x00, 0x24, 0x40section .textglobal mainmain:push   ebpmov    ebp,espand    esp,0xfffffff0sub    esp,0x20fld    qword [S_80484f0]fstp   QWORD [esp+0x18]fld    QWORD [esp+0x18]fstp   QWORD [esp+0x4] mov    DWORD [esp],S_80484d0call   printfleaveretThen 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 
Why ther are some many padding/leading nop instructions in my binary code?
disassembly;assembly;elf
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.