delorie.com/archives/browse.cgi   search  
Mail Archives: djgpp/2007/01/23/18:01:37

X-Authentication-Warning: delorie.com: mail set sender to djgpp-bounces using -f
Message-ID: <BAY119-F29593B3F537C55B2623E3E3AD0@phx.gbl>
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" <roland_djgpp AT hotmail DOT com>
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
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/

- Raw text -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019