@Stefan: Thanks a lot for replying. These are the excerpts from http://www.uclibc.org/docs/psABI-i386.pdf (Section 2.2.2. Page 10): "The end of the input argument area shall be aligned on a 16 (32, if __m256 is passed on stack) byte boundary. In other words, the value (%esp + 4) is always a multiple of 16 (32)when control is transferred to the function entry point." This means that even i386 ABI mandates 16-byte (or 32-byte) alignment of stack. Hence, these 3 assembly instructions should have been generated for x86_64 architecture as well.
@Jonathan: The reason I started this discussion is due to my suspicion of a potential bug in gcc-4.9.2. However, I may be wrong. Here is the explanation: As per the discussion in this thread, it is clear that both i386 ABI and AMD64 ABI (http://www.x86-64.org/documentation/abi.pdf, Section 3.3.2) mandates 16 (or 32) byte stack alignment once the control reaches at function entry point. 1. If these 3 assembly instructions are being generated to fulfill the stack alignment condition for 'main' function, then it leads me to believe 2 things: a) These 3 assembly instructions should have been generated for x86_64 architecture as well. But they are not. b) If we focus on one of the statements I wrote above "In other words, the value (%esp + 4) is always a multiple of 16 (32) when control is transferred to the function entry point", the alignment should not have happened inside main function rather before the control transfers to main function. Hence, these 3 assembly instructions should have never been a part of the 'main' function but the function calling 'main'. 2. If these 3 assembly instructions are not generated to fulfill stack alignment condition for 'main' function but for some function called from inside main ( 'printf' in this case), then it should have been done for x86_64 case also. Please mention if I am missing anything here. Thanks On Mon, Oct 12, 2015 at 1:05 PM, Abhishek Aggarwal <abhiinnit...@gmail.com> wrote: > > @Stefan: Thanks a lot for replying. These are the excerpts from > http://www.uclibc.org/docs/psABI-i386.pdf (Section 2.2.2. Page 10): > "The end of the input argument area shall be aligned on a 16 (32, if __m256 > is passed on stack) byte boundary. In other words, the value (%esp + 4) is > always a multiple of 16 (32) when control is transferred to the function > entry point." > This means that even i386 ABI mandates 16-byte (or 32-byte) alignment of > stack. Hence, these 3 assembly instructions should have been generated for > x86_64 architecture as well. > > > @Jonathan: The reason I started this discussion is due to my suspicion of a > potential bug in gcc-4.9.2. However, I may be wrong. Here is the > explanation: > > As per the discussion in this thread, it is clear that both i386 ABI and > AMD64 ABI (http://www.x86-64.org/documentation/abi.pdf, Section 3.3.2) > mandates 16 (or 32) byte stack alignment once the control reaches at > function entry point. > > 1. If these 3 assembly instructions are being generated to fulfill the stack > alignment condition for 'main' function, then it leads me to believe 2 > things: > a) These 3 assembly instructions should have been generated for x86_64 > architecture as well. But they are not. > b) If we focus on one of the statements I wrote above "In other words, > the value (%esp + 4) is always a multiple of 16 (32) when control is > transferred to the > function entry point", the alignment should not have happened > inside main function rather before the control transfers to main function. > Hence, these 3 assembly > instructions should have never been a part of the 'main' function > but the function calling 'main'. > > 2. If these 3 assembly instructions are not generated to fulfill stack > alignment condition for 'main' function but for some function called from > inside main ( 'printf' in this case), then it should have been done for > x86_64 case also. > > Please mention if I am missing anything here. > > Thanks >
