问题

I don't entirely understand the line with comment in it below. I read a few posts on SO and in the gcc manual and learned that it is for stack address alignment but fail to understand how it does so. The code is show below:

(gdb) disas main

Dump of assembler code for function main:

0x08048414 : push ebp

0x08048415 : mov ebp,esp

0x08048417 : and esp,0xfffffff0 ; why??

0x0804841a : sub esp,0x10

0x0804841d : mov DWORD PTR [esp],0x8048510

0x08048424 : call 0x8048320

0x08048429 : mov DWORD PTR [esp],0x8048520

0x08048430 : call 0x8048330

0x08048435 : leave

0x08048436 : ret

End of assembler dump.

The code was generated using gcc (version 4.6.3) on linux. Thanks.

回答1:

and esp, 0xfffffff0 does a bitwise AND between the stack pointer and a constant, and stores the result back in the stack pointer.

The constant is chosen so that its low four bits are zero. Therefore the AND operation will set these bits to zero in the result, and leave the other bits of esp intact. This has the effect of rounding the stack pointer down to the nearest multiple of 16.

回答2:

It looks like it's part of some code to set up shop at the start of main.

Function start: save the base frame pointer on the stack (needed by the leave instruction later):

0x08048414 : push ebp

Now we align the stack pointer to a 16-byte bound, because the compiler (for whatever reason) wants it. This could be that it always wants 16-byte aligned frames, or that the local variables need 16-byte alignment (maybe someone used a uint128_t or they're using a type that uses gcc vector extensions). Basically, since the result will always be less than or equal to the current stack pointer, and the stack grows downward, it's just discarding bytes until it gets to a 16-byte aligned point.

0x08048415 : mov ebp,esp

0x08048417 : and esp,0xfffffff0

Next we subtract 16 from the stack pointer, creating 16 bytes of local variable space:

0x0804841a : sub esp,0x10

puts((const char*)0x8048510);

0x0804841d : mov DWORD PTR [esp],0x8048510

0x08048424 : call 0x8048320

system((const char*)0x8048520);

0x08048429 : mov DWORD PTR [esp],0x8048520

0x08048430 : call 0x8048330

Exit the function (see another answer about what leave does):

0x08048435 : leave

0x08048436 : ret

Example of "discarding bytes": say esp = 0x123C at the start of main. The first lines of code:

0x08048414 : push ebp

0x08048415 : mov ebp,esp

result in this memory map:

0x123C: (start of stack frame of calling function)

0x1238: (old ebp value)

Then:

0x08048417 : and esp,0xfffffff0

forces the last 4 bits of esp to 0, which does this:

0x123C: (start of stack frame of calling function)

0x1238: (old ebp value)

0x1234: (undefined)

0x1230: (undefined)

There's no way for the programmer to rely on a certain amount of memory being between esp and ebp at this point; therefore this memory is discarded and not used.

Finally, the program allocates 16 bytes of stack (local) storage:

Next we subtract 16 from the stack pointer, creating 16 bytes of local variable space:

0x0804841a : sub esp,0x10

giving us this map:

0x123C: (start of stack frame of calling function)

0x1238: (old ebp value)

0x1234: (undefined)

0x1230: (undefined)

0x123C: (undefined local space)

0x1238: (undefined local space)

0x1234: (undefined local space)

0x1230: (undefined local space)

At this point, the program can be sure there are 16 bytes of 16-byte aligned memory being pointed to by esp.

回答3:

i know it was posted long time ago, it might help for others down the line.

1) In modern processors, we know that GCC aligns the stack defaulting to 16-byte alignment.

2) 16 byte ( 128 bit ) is because of SSE2 instructions which have MMX and XMM registers and XMM registers are of 128 bit.

3) so when a function call is made, it is automatically aligned to 16 byte, outside the function it remains to 8 byte.

4) the logic of using 0xfffffff0 is to keep the lower 4 bit to 0 , this is because of simple Boolean math which says that in binary , the multiples of 16 have low 4 bit to zero ( why four bits? 2^4 = 16 ).

来源：https://stackoverflow.com/questions/24588858/and-esp-0xfffffff0