Bug: BSS segment in COFF files

Bug: BSS segment in COFF files

[Wolfgang Hesseler]

Hello,
I'm trying to link some code compiled with the Cygwin gcc compiler with
the Watcom linker. This works as the Watcom linker supports the COFF
object code format. However, there seems to be a problem with
uninitialized variables. After analyzing an object file it seems as if
the BSS segment always has size 0 so that the Cygwin generated object
files are not valid COFF files. Is this a known problem?

I ended up in making all uninitialized data to 0-inialized variables.
Is there any better way?


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: Bug: BSS segment in COFF files

[egor duda]

Hi!

Friday, 12 July, 2002 Wolfgang Hesseler qv@multimediaware.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:deo@logos-m.ru ICQ 5165414 FidoNet 2:5020/496.19


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: Bug: BSS segment in COFF files

[Wolfgang Hesseler]

> 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.

This works, however only if the variables are non-static. If a 
variable is static the .comm directive is still used.
 
> 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_'.

The only problem is that some functions call external functions 
like _log10. Is the cygwin1.dll source code of that function available?
I did a quick search in CVS but couldn't find it.


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: Bug: BSS segment in COFF files

[egor duda]

Hi!

Friday, 12 July, 2002 Wolfgang Hesseler qv@multimediaware.com wrote:

>> 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.

WH> This works, however only if the variables are non-static. If a 
WH> variable is static the .comm directive is still used.

.lcomm, to be precise.

That's easy to work around. Just add 'int dummy;' to your source
file compiled with gcc, and you have 4 bytes in bss section.
 
>> 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_'.

WH> The only problem is that some functions call external functions 
WH> like _log10. Is the cygwin1.dll source code of that function available?
WH> I did a quick search in CVS but couldn't find it.

They're from newlib. http://sources.redhat.com/newlib/

Again, i suppose Watcom runtime provide log10 function, but symbol is
probably named log10_ or log10, not _log10. And you also have to check
that calling conventions and 'float' and 'double' formats (if you're
using floats) are compatible if you want your modules to interoperate.

Egor.            mailto:deo@logos-m.ru ICQ 5165414 FidoNet 2:5020/496.19


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: Bug: BSS segment in COFF files

[Wolfgang Hesseler]

> >> 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.
> 
> WH> This works, however only if the variables are non-static. If a
> WH> variable is static the .comm directive is still used.
> 
> .lcomm, to be precise.
> 
> That's easy to work around. Just add 'int dummy;' to your source
> file compiled with gcc, and you have 4 bytes in bss section.

But how does this help? The other static variables still use 
the .lcomm directive.


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: Bug: BSS segment in COFF files

[egor duda]

Hi!

Friday, 12 July, 2002 Wolfgang Hesseler qv@multimediaware.com wrote:

>> >> 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.
>> 
>> WH> This works, however only if the variables are non-static. If a
>> WH> variable is static the .comm directive is still used.
>> 
>> .lcomm, to be precise.
>> 
>> That's easy to work around. Just add 'int dummy;' to your source
>> file compiled with gcc, and you have 4 bytes in bss section.

WH> But how does this help? The other static variables still use 
WH> the .lcomm directive.

Ah, i was thinking the problem is that wlink refuses to link in
modules with empty .bss section.

The problem seems to be that you can't reference to static variable
from within the module.

You can add

#ifdef GCC
#define STATIC static __attribute__ ((section(".bss")))
#else
#define STATIC static
#endif

and then replace all 'static some_type some_var;' with
'STATIC some_type some_var;', although i don't know if such tricks are
guaranteed to work with all current and future versions of gcc.

Egor.            mailto:deo@logos-m.ru ICQ 5165414 FidoNet 2:5020/496.19


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: Bug: BSS segment in COFF files

[Wolfgang Hesseler]

> >> >> 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.

I just noticed that this doesn't help at all. When analyzing the 
object file with IDA you'll see that the BSS section has length 0.
Thus, when you link several object files together, all variables
are at the same memory position. I think it's a problem with the
Assembler that doesn't generate valid COFF files. BTW, when 
compiling the same program under Linux the BSS section is not 0. So,
it seems that the problem is Cygwin (COFF) specific.

So far, the only way to reserve memory for a variable is to make
it 0-initialized.


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: Bug: BSS segment in COFF files

[egor duda]

Hi!

Friday, 12 July, 2002 egor duda deo@logos-m.ru wrote:

ed> Friday, 12 July, 2002 Wolfgang Hesseler qv@multimediaware.com wrote:

>>> >> 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.
>>> 
>>> WH> This works, however only if the variables are non-static. If a
>>> WH> variable is static the .comm directive is still used.
>>> 
>>> .lcomm, to be precise.
>>> 
>>> That's easy to work around. Just add 'int dummy;' to your source
>>> file compiled with gcc, and you have 4 bytes in bss section.

WH>> But how does this help? The other static variables still use 
WH>> the .lcomm directive.

Hmm. I should have checked first. I'm wrong. Variables declared as
.lcomm _are_ put into .bss section in .o file.

ed> The problem seems to be that you can't reference to static variable
ed> from within the module.

[...]

Egor.            mailto:deo@logos-m.ru ICQ 5165414 FidoNet 2:5020/496.19


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: Bug: BSS segment in COFF files

[egor duda]

Hi!

Friday, 12 July, 2002 Wolfgang Hesseler qv@multimediaware.com wrote:

>> >> >> 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.

WH> I just noticed that this doesn't help at all. When analyzing the 
WH> object file with IDA you'll see that the BSS section has length 0.
WH> Thus, when you link several object files together, all variables
WH> are at the same memory position. I think it's a problem with the
WH> Assembler that doesn't generate valid COFF files. BTW, when 
WH> compiling the same program under Linux the BSS section is not 0. So,
WH> it seems that the problem is Cygwin (COFF) specific.

WH> So far, the only way to reserve memory for a variable is to make
WH> it 0-initialized.

Huh?

$ cat x.c
int a;
static int b[10000];
$ gcc -fno-common -save-temps -c x.c
$ cat x.s
        .file   "x.i"
.globl _a
        .bss
        .align 4
_a:
        .space 4
.lcomm _b,40000
$ objdump --section-headers x.o
Idx Name          Size      VMA       LMA       File off  Algn
  0 .text         00000000  00000000  00000000  00000000  2**2
                  ALLOC, LOAD, CODE
  1 .data         00000000  00000000  00000000  00000000  2**2
                  ALLOC, LOAD, DATA
  2 .bss          00009c48  00000000  00000000  00000000  2**2
                  ALLOC

Egor.            mailto:deo@logos-m.ru ICQ 5165414 FidoNet 2:5020/496.19


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: Bug: BSS segment in COFF files

[Wolfgang Hesseler]

> $ cat x.c
> int a;
> static int b[10000];
> $ gcc -fno-common -save-temps -c x.c
> $ cat x.s
>         .file   "x.i"
> .globl _a
>         .bss
>         .align 4
> _a:
>         .space 4
> .lcomm _b,40000
> $ objdump --section-headers x.o
> Idx Name          Size      VMA       LMA       File off  Algn
>   0 .text         00000000  00000000  00000000  00000000  2**2
>                   ALLOC, LOAD, CODE
>   1 .data         00000000  00000000  00000000  00000000  2**2
>                   ALLOC, LOAD, DATA
>   2 .bss          00009c48  00000000  00000000  00000000  2**2
>                   ALLOC

Right. But the whole Cygwin wouldn't work if its programs wouldn't recognize
its own object code properly. My problem is that Cygwin produces
some non-standard COFF object files. I will do some experiments with
objcopy and see if that helps to solve the problem.


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: Bug: BSS segment in COFF files

[egor duda]

Hi!

Friday, 12 July, 2002 Wolfgang Hesseler qv@multimediaware.com wrote:

>> $ cat x.c
>> int a;
>> static int b[10000];
>> $ gcc -fno-common -save-temps -c x.c
>> $ cat x.s
>>         .file   "x.i"
>> .globl _a
>>         .bss
>>         .align 4
>> _a:
>>         .space 4
>> .lcomm _b,40000
>> $ objdump --section-headers x.o
>> Idx Name          Size      VMA       LMA       File off  Algn
>>   0 .text         00000000  00000000  00000000  00000000  2**2
>>                   ALLOC, LOAD, CODE
>>   1 .data         00000000  00000000  00000000  00000000  2**2
>>                   ALLOC, LOAD, DATA
>>   2 .bss          00009c48  00000000  00000000  00000000  2**2
>>                   ALLOC

WH> Right. But the whole Cygwin wouldn't work if its programs wouldn't recognize
WH> its own object code properly. My problem is that Cygwin produces
WH> some non-standard COFF object files. I will do some experiments with
WH> objcopy and see if that helps to solve the problem.

I suppose it's too early to call it non-standard without strong
evidence. For now, you have found that it's somehow incompatible with
ida and/or watcom linker, though i did test linking x.o with
watcom-compiled test.obj using wlink and everything worked fine.

$ cat x.mk
project : f:\test\x.exe .SYMBOLIC

!include f:\test\x.mk1
$ cat x.mk1
f:\test\test.obj : f:\test\test.c .AUTODEPEND
 @f:
 cd f:\test
 *wcc386 test.c -i=e:\w32app\prog\watc10\h;e:\w32app\prog\watc10\h\nt -w4 -e&
25 -zq -otexan -d2 -mf -5r -bt=nt

f:\test\x.exe : f:\test\test.obj f:\test\x.o .AUTODEPEND
 @f:
 cd f:\test
 @%write x.lk1 NAME x
 @%append x.lk1 FIL test.obj
 @%append x.lk1 FIL x.o
 @%append x.lk1 
 *wlink SYS nt op m d all op st=8192 op maxe=25 op q op symf @x.lk1

$ wmake -f x.mk
Watcom Make Version 11.0
Copyright by Sybase, Inc., and its subsidiaries, 1988, 1997.
All rights reserved.  Watcom is a trademark of Sybase, Inc.
        cd f:\test
        wcc386 test.c -i=e:\w32app\prog\watc10\h;e:\w32app\prog\watc10\h\nt -w4
-e25 -zq -otexan -d2 -mf -5r -bt=nt
test.c(5): Warning! W107: Missing return value for function 'main'
test.c(5): Warning! W301: No prototype found for 'printf'
        cd f:\test
        wlink SYS nt op m d all op st=8192 op maxe=25 op q op symf @x.lk1
$ ./x.exe
1

Egor.            mailto:deo@logos-m.ru ICQ 5165414 FidoNet 2:5020/496.19


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: Bug: BSS segment in COFF files

[Wolfgang Hesseler]

> I suppose it's too early to call it non-standard without strong
> evidence. For now, you have found that it's somehow incompatible with
> ida and/or watcom linker, though i did test linking x.o with
> watcom-compiled test.obj using wlink and everything worked fine.

The solution is to use non-static variables only. The Watcom linker
will then link properly. I still think the file is non standard though.

Here is an example that shows the problem:

file a.c: (compile with gcc)
static int a;
void function1_(void)
{ a=123; }

file b.c: (compile with gcc)
static int b;
int function2_(void)
{ return b;}

file test.c: (compile with Watcom)
#include <stdio.h>
extern void _function1(void);
extern int _function2(void);
void main(void)
{
  _function1();
  printf("%d\n",_function2());
}

It will print 123 even if b was never given a value. This is because
a and b are linked to the same memory position. If the variables a and
b are public you will get the expected 0.

BTW, don't use -fno-common. If you do it, even non-static variables
are linked at the same memory position.


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/