This is the mail archive of the
mailing list for the Cygwin project.
Re: Bug: BSS segment in COFF files
- From: egor duda <deo at logos-m dot ru>
- To: Wolfgang Hesseler <qv at multimediaware dot com>
- Cc: cygwin at cygwin dot com
- Date: Fri, 12 Jul 2002 14:51:34 +0400
- Subject: Re: Bug: BSS segment in COFF files
- Organization: deo
- References: <3D2EA2E2.firstname.lastname@example.org>
- Reply-to: egor duda <cygwin at cygwin dot com>
Friday, 12 July, 2002 Wolfgang Hesseler email@example.com wrote:
WH> I'm trying to link some code compiled with the Cygwin gcc compiler with
WH> the Watcom linker. This works as the Watcom linker supports the COFF
WH> object code format. However, there seems to be a problem with
WH> uninitialized variables. After analyzing an object file it seems as if
WH> the BSS segment always has size 0 so that the Cygwin generated object
WH> files are not valid COFF files. Is this a known problem?
WH> I ended up in making all uninitialized data to 0-inialized variables.
WH> Is there any better way?
If you run gcc with '--save-temps' flag, and then look into
'yourfile.s' file, you'll see that uninitialized data is tagged as
"common" (using '.comm' directive) and is put to bss only by linker
when final executable is created. To turn this feature off, use
'-fno-common' flag when compiling your object file.
Not sure if it's all that needed to link gcc-produced object files
with watcom linker, though. For instance, for function 'func ()' gcc
uses _func as symbol name in object files while watcom uses 'func_'.
But in a simple testcase i've just tried, in which only data is
imported from gcc-compiled object everything seems to work ok.
Egor. mailto:firstname.lastname@example.org ICQ 5165414 FidoNet 2:5020/496.19
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html