This is the mail archive of the gcc-help@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Stack frame question on x86 code generation


First of all, thanks for your kind response.
I have a couple of follow up questions. 
My questions are below.

Best regards,

--- Niko Matsakis <niko@alum.mit.edu> wrote:
> > I compiled with gcc -O0 -S option and the compiler
> > produces the code that I cannot quite follow the
> > stack frame layout strategy in gcc.
> 
> First of all, I think you'll find in more
> complicated functions that 
> the stack layout for -O3 is dramatically different. 
> This is partly 
> because many variables do not need to end up on the
> stack, and the 
> effect of other optimizations.
Yes, I have a very clear understanding that (1) the
optimizer
can map the lifetime of variables to registers so
that, the
stack frame size can differ. (2) how the activation
record is constructed by caller and callee.

It appears that gcc seems to generate code to make
%esp aligned
in 16bytes boundary. If this correct, then what is the
benefit in
x86. Why 2 words boundary? Targeting for I64? Are
there any
x86 instructions to exploit such alighment to reduce
the
function call overhead or context switch?

However, my first question still remains since I
cannot 
reasoning about the 16 bytes padding for the array
buffer1. 

Thanks again for your help.

> 
> Hopefully this is just for educational purposes, and
> you're not 
> planning on writing code that relies on the layout
> of the stack frame!  
> I can guarantee you that this will change.  If you
> just want to find 
> the return address, there are easier ways...
> 
> Anyway, on to your questions:
> 
> > question1: Why the stack frame size is 56?
> >            observation: (1) compiler add 16 bytes
> >            padding before allocating storage
> >            for array buffer1 (2) buffer1 need
> >            5 bytes. However, due to alignment
> >            issue, they seem to add 3 extra bytes.
> >            Thus, -24(%ebp) should point to
> buffer1[0].
> >
> >            Then, why they adding 16 bytes padding?
> 
> I can't say for sure, but remember that the stack
> frame has more than 
> just variables on it.  There are also saved
> registers, such as the 
> caller's frame pointer, and a number of other
> things.  Also, many 
> machines work best if they 32 bit alignment for
> memory loads.
> 
> > question2: Why gcc makes the stack frame bigger
> before
> >
> >            the function call printf?
> >
> >                   subl    $8, %esp
> >
> >            Does it related to printf? If it does,
> then
> >            could you explain why?
> 
> This is to make room for the parameters to printf();
> there are two, and 
> each is a pointer, and hence four bytes, so the
> total space required is 
> eight bytes.
> 
> 
> Niko
> 
> 

__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com 


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]