[ale] linux byte alignment

[stephen]

On Mon, Jul 29, 2002 at 07:29:11PM -0400, stephen wrote:
> On Mon, Jul 29, 2002 at 03:26:09PM -0400, Benjamin Dixon wrote:
> > 
> > Hi all,
> > 
> > I'm trying to pry into linux byte alignment issues and assembly and I ran
> > across something I haven't figured out. My understanding is that alignment
> > is at one word (4 bytes) so I have the following function:
> > 
> > int main()
> > {
> >    char x[10];
> >    char y[5];
> > }
> > 
> > By my calculation, if the memory has to be alignment, x[10] will take up
> > 12 bytes (ceiling of 2.5 words = 3, 3x4-bytes = 12). And likewise, the
> > y[5] will take up 8 bytes. So there's 20 bytes of excess memory laying
> > around? But when I run the program through gcc with the -S option, I get
> > the following:
> > 
> > ...
> > main:
> >         pushl %ebp
> >         movl %esp,%ebp
> >         subl $40,%esp
> > .L2:
> >         movl %ebp,%esp
> >         popl %ebp
> >         ret
> > .Lfe1:
> > ...
> > 
> > The question is, what's that 40? If I use different numbers for the array
> > sizes, I get a different number there, always divisible by 4 but always
> > greater than the number I expect. Anyone know why?
> 
> I'm not sure why the compiler produces this, but if you disassemble the
> the binary then you should see the expected 20 bytes for x and y plus room
> for the frame pointer and return address.  This is a snippet of what I got
> from 'objdump -d':
> 
> [snip]
> 080483a4 <main>:
>  80483a4:	55                   	push   %ebp
>  80483a5:	89 e5                	mov    %esp,%ebp
>  80483a7:	83 ec 28             	sub    $0x28,%esp
                                                ^^
EEEKKK...nevermind me.  It's been a long day.

stephen

---
This message has been sent through the ALE general discussion list.
See http://www.ale.org/mailing-lists.shtml for more info. Problems should be 
sent to listmaster at ale dot org.