X-Authentication-Warning: delorie.com: mail set sender to djgpp-bounces using -f Message-ID: X-Originating-IP: [84.30.231.182] X-Originating-Email: [roland_djgpp AT hotmail DOT com] X-Sender: roland_djgpp AT hotmail DOT com From: "Pablo Fujii" To: djgpp AT delorie DOT com Subject: BSS problem in DJGPP port of GCC 4 (was: Re: Question about djcross-gcc-4.1.1-2) Date: Wed, 24 Jan 2007 10:47:07 +1200 Mime-Version: 1.0 Content-Type: text/plain; format=flowed X-OriginalArrivalTime: 23 Jan 2007 22:47:09.0352 (UTC) FILETIME=[6A144A80:01C73F40] Reply-To: djgpp AT delorie DOT com >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). Actually, the -fno-exceptions causes files like eh_alloc.o not to be linked into the resulting executable. The stdc++ library is compiled with several compiler flags, one of them being -fdata-sections. Consider the following small test program: --- cut begin--- static int int_array[500000]; int main (void) { return 0; } --- cut end--- Compiling this C file *without* the -fdata-sections option gives the desired output: $ i586-pc-msdosdjgpp-size bss_test.exe text data bss dec hex filename 44488 3072 2014208 2061768 1f75c8 bss_test.exe $ i586-pc-msdosdjgpp-objdump -h bss_test.o bss_test.o: file format coff-go32 Sections: Idx Name Size VMA LMA File off Algn 0 .text 00000020 00000000 00000000 000000b4 2**4 CONTENTS, ALLOC, LOAD, CODE 1 .data 00000000 00000000 00000000 00000000 2**4 ALLOC, LOAD, DATA 2 .bss 001e8480 00000000 00000000 00000000 2**2 ALLOC 3 .comment 00000014 00000000 00000000 000000d4 2**2 CONTENTS, DEBUGGING Compiling this C file *with* the -fdata-sections option gives "wrong" output: $ i586-pc-msdosdjgpp-size bss_test.exe text data bss dec hex filename 44488 2017280 0 2061768 1f75c8 bss_test.exe $ i586-pc-msdosdjgpp-objdump -h bss_test.o bss_test.o: file format coff-go32 Sections: Idx Name Size VMA LMA File off Algn 0 .text 00000020 00000000 00000000 000000dc 2**4 CONTENTS, ALLOC, LOAD, CODE 1 .data 00000000 00000000 00000000 00000000 2**4 ALLOC, LOAD, DATA 2 .bss 00000000 00000000 00000000 00000000 2**2 ALLOC 3 .bss.int_array 001e8480 00000000 00000000 000000fc 2**2 CONTENTS, ALLOC, LOAD, DATA 4 .comment 00000014 00000000 00000000 001e857c 2**2 CONTENTS, DEBUGGING As indicated before, the native GCC 4.1.1 compiler of e.g. Fedora Core 6 does not have this problem: $ objdump -h bss_test.o bss_test.o: file format elf32-i386 Sections: Idx Name Size VMA LMA File off Algn 0 .text 00000019 00000000 00000000 00000034 2**2 CONTENTS, ALLOC, LOAD, READONLY, CODE 1 .data 00000000 00000000 00000000 00000050 2**2 CONTENTS, ALLOC, LOAD, DATA 2 .bss 00000000 00000000 00000000 00000050 2**2 ALLOC 3 .bss.int_array 001e8480 00000000 00000000 00000060 2**5 ALLOC 4 .comment 0000002e 00000000 00000000 00000060 2**0 CONTENTS, READONLY 5 .note.GNU-stack 00000000 00000000 00000000 0000008e 2**0 CONTENTS, READONLY Comparison of the generated assembler files, first the one by created by DJGPP GCC 4.1.0: .file "bss_test.c" .section .text ..globl _main _main: leal 4(%esp), %ecx ... ret .section .bss.int_array,"w" .p2align 5 _int_array: .space 2000000 .ident "GCC: (GNU) 4.1.0" And here's the assembler file generated by native GCC 4.1.1: .file "bss_test.c" .text ..globl main .type main, @function main: leal 4(%esp), %ecx ... ret .size main, .-main .section .bss.int_array,"aw",@nobits .align 32 .type int_array, @object .size int_array, 2000000 int_array: .zero 2000000 .ident "GCC: (GNU) 4.1.1 20070105 (Red Hat 4.1.1-51)" .section .note.GNU-stack,"",@progbits Maybe someone can explain the differences in section .bss.int_array? Best regards, Roland _________________________________________________________________ Express yourself instantly with MSN Messenger! Download today it's FREE! http://messenger.msn.click-url.com/go/onm00200471ave/direct/01/