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

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.
> 
> So I tried to reproduce this with a smaller program, which is attached
> to this mail. Compiling and linking it with 586-pc-msdosdjgpp-gcc
> works fine, but when compiling with 586-pc-msdosdjgpp-g++ the array
> int_array is no longer part of the .bss section. Conclusion: the
> problem must be in one of the C++ libraries.
> 
> Looking at the loader script
> /usr/i586-pc-msdosdjgpp/lib/ldscripts/i386go32.x you'll see that the
> following sections are all merged into .bss: .bss .bss.*
> gnu.linkonce.b.* . After playing a bit with the loader script I found
> that at least one of the .bss.* sections is causing the problem.
> 
> The command "i586-pc-msdosdjgpp-objdump -h
> /usr/lib/gcc/i586-pc-msdosdjgpp/4.1.1/libstdc++.a" shows that there
> are numerous .bss.* sections having the "CONTENTS, ALLOC, LOAD, DATA"
> attributes. For comparison with my system's GCC compiler I also ran
> the command "objdump -h
> /usr/lib/gcc/i386-redhat-linux/4.1.1/libstdc++.a" and there all the
> bss.* sections only have the ALLOC attribute.
> 
> And here I'm stuck. It looks like libstdc++.a needs to be rebuild, but
> I have no clue what to change.
> 
> Also I'm not able to rebuild the binary RPM package from the source
> package on my Fedora Core 6 system. One of the things I had to change
> was to add the line "export SHORTVER=`echo %{version} | sed -e
> 's:\.::2g'`" to the %build step of the djcross-gcc.spec file). Then
> after building the compiler in tmpbuild the rpmbuild command stopped
> with an error, but I've forgotten what exactly went wrong.
> 
> Are you familiar with the empty .bss section problem and do you have
> an idea how it can be solved?
> 
> Best regards,
> Roland Hermans
> 
> 
> ------------------------------------------------------------------------
> 
> #include <stdio.h>
> #include <stdlib.h>
> 
> #define ARRAY_SIZE	500000
> 
> static int int_array[ARRAY_SIZE];
> 
> int main (void) {
>     int i;
> 
>     for (i = 0; i < ARRAY_SIZE; i++) {
> 	int_array[i] = i;
>     }
> 
>     printf("done\n");
> 
>     return 0;
> }

With this example I'm getting after compiler:
Sections:
Idx Name          Size      VMA       LMA       File off  Algn
   0 .text         00000060  00000000  00000000  000000dc  2**4
                   CONTENTS, ALLOC, LOAD, RELOC, CODE
   1 .data         00000000  00000000  00000000  00000000  2**4
                   ALLOC, LOAD, DATA
   2 .bss          001e8480  00000000  00000000  00000000  2**2
                   ALLOC
   3 .eh_frame     00000048  00000000  00000000  0000013c  2**2
                   CONTENTS, ALLOC, LOAD, RELOC, DATA
   4 .comment      00000014  00000000  00000000  00000184  2**2
                   CONTENTS, DEBUGGING

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

PS. Sending also to DJGPP mailing list. Maybe somebody have better ideas.