Mail Archives: djgpp/2007/01/23/18:01:46
>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/
- Raw text -