From: gordonb DOT 1l94a AT sneaky DOT lerctr DOT org (Gordon Burditt)
Newsgroups: comp.os.msdos.djgpp,comp.lang.c
Subject: Re: DJGPP reserves wrong int size
Date: 24 Jun 2001 20:41:03 GMT
Organization: Airnews.net! at Internet America
Lines: 70
Message-ID: <F4D3B4429C4C5C09.AF296AB1B53F01AC.8E297A15322C757D@lp.airnews.net>
X-Orig-Message-ID: <9h5j8v$6rb AT library2 DOT airnews DOT net>
References: <9dde68b7 DOT 0106241053 DOT 2a385311 AT posting DOT google DOT com>
Abuse-Reports-To: abuse at airmail.net to report improper postings
NNTP-Proxy-Relay: library2.airnews.net
NNTP-Posting-Time: Sun Jun 24 15:41:03 2001
NNTP-Posting-Host: !ZPo#1k-Y1ftn^Q66SB58KomV (Encoded at Airnews!)
X-Newsreader: trn 4.0-test76 (Apr 2, 2001)
Originator: gordon AT gerbil DOT hammy DOT lonestar DOT org (Gordon Burditt)
To: djgpp AT delorie DOT com
DJ-Gateway: from newsgroup comp.os.msdos.djgpp
Reply-To: djgpp AT delorie DOT com

>int main () 
>{
>int i;
>i = 0x12345678;
>}
>
>-Yes I am aware there is no return statement even if I do have it in there 
>it still messes up.
>When I compile this code using:
>
>gcc -c test.c
>ld -o test -Ttext 0x0 -e main test.o
>objcopy -R .note -R .comment -S -O binary test test.bin
>
>and disassemble it I get the following:

Stop disassembling it and the "problem" will go away.  Nobody
guaranteed that the compiler will operate in stack-stingy mode.

>00000000 55                          push ebp
>00000001 89E5                        mov ebp,esp
>00000003 83EC04                      sub esp,byte +0x18
>00000006 C745FC78563412              mov dword [ebp-0x4],0x12345678
>0000000D C9                          leave
>0000000E C3                          ret
>
>The third line reserves 18 bytes.

That's 24, decimal.

>And it should reserve 4 bytes because thats the size of an int right?

NO.  The compiler is probably allocating memory for an entire stack
frame, including temporary memory areas it might or might not need.
Your function does not call other functions.  It is not complicated
enough to use registers whose values have to be saved and restored
across function calls.

>If you declare a char it still reserves 18 bytes.

Think about alignment.

The compiler seems to be keeping a stack alignment of 16 bytes,
(one cache line for some processors) counting (a) the 4 bytes in
the return address pushed by the caller, and (b) the 4 bytes pushed
by the pushl %ebp, and (c) 8 bytes it seems to want for itself.

Note that if you call a function with 2 (4-byte each) int arguments, it
also adjusts the stack so the total adjustment is 16 bytes.

If you use -O the initialized but unused auto variables disappear
entirely.  So does the stack reservation for them.


>Could someone tell me what's going on?  I am loosing my mind!

Don't waste it on trying to second-guess the compiler.

>Line 4 is correct though.
>
>I am compiling this on Windows 98 and ME boxes and still get the same results.
>The gcc version number is 2.953
>binutills is version 2.11

I get similar results on FreeBSD with GCC 2.95.3.  The assembly
code is easier to understand if you use -S and don't bother
disassembling (or assembling), just look at the assembly-language
output.

						Gordon L. Burditt