X-Authentication-Warning: delorie.com: mail set sender to djgpp-bounces using -f
Message-ID: <45B50BD6.5010900@iki.fi>
Date: Mon, 22 Jan 2007 21:09:10 +0200
From: Andris Pavenis <andris DOT pavenis AT iki DOT fi>
User-Agent: Thunderbird 2.0b1 (X11/20061206)
MIME-Version: 1.0
To: djgpp AT delorie DOT com
Cc: Roland Hermans <roland DOT hermans AT gmail DOT com>
Subject: Re: Question about djcross-gcc-4.1.1-2
References: <578224990701211526q65964c83hc544dbf8d16c596b AT mail DOT gmail DOT com> <45B459B1 DOT 4000608 AT iki DOT fi>
In-Reply-To: <45B459B1.4000608@iki.fi>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Reply-To: djgpp AT delorie DOT com

Andris Pavenis wrote:
> Roland Hermans wrote:
>> Andris,
>>
>> Many thanks for providing the DJGPP cross compiler on Fedora.
>>
>> Unfortunately I'm having a problem with it while porting my C++
>> application to the DJGPP platform. The problem is that the resulting
>> executable is much larger (in total about 7 MB) than when compiling
>> directly with DJGPP (around 500 KB).
>>
>> Examing the executables with 586-pc-msdosdjgpp-size shows that the bss
>> section is 0 when compiling and linking the sources with the
>> djcross-gcc package. When looking at the section headers with
>> 586-pc-msdosdjgpp-objdump -h <exe> I see this:
>>
>> Idx Name          Size      VMA       LMA       File off  Algn
>>  0 .text         000735c8  00001a38  00001a38  00001a38  2**4
>>                  CONTENTS, ALLOC, LOAD, CODE
>>  1 .data         0000ee00  00075000  00075000  00075000  2**4
>>                  CONTENTS, ALLOC, LOAD, DATA
>>  2 .bss          006a7000  00083e00  00083e00  00083e00  2**2
>>                  CONTENTS, ALLOC
>>
>> As you can see, the .bss section has the CONTENTS attribute (or
>> whatever it's called) which causes the linker to allocate space for
>> this section in the resulting executable. The interesting part is how
>> this can happen. The sections of all my compiled object files only
>> have the ALLOC attribute, so it must be one of the compiler libraries.
>>
> 
> The problem only seems to appear after linking. So I guess it is in 
> binutils. I also saw the same with native gcc-4.1.1 under DosEmu. 
> Unfortunately I cannot say much more now and don't currently have time 
> for studying it more.
> 
> Andris

It seems to be bug in binutils. It does not appear even in C++ when 
option -fno-exceptions is specified (so no .eh_frame section).