Mail Archives: djgpp/2007/01/22/01:59:50
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.
- Raw text -