Mailing-List: contact cygwin-help AT sourceware DOT cygnus DOT com; run by ezmlm
Sender: cygwin-owner AT sources DOT redhat DOT com
Message-ID: <39BF8F41.89391ED6@e-14.com>
Date: Wed, 13 Sep 2000 15:29:21 +0100
From: Nigel Wetten <nwetten AT e-14 DOT com>
MIME-Version: 1.0
To: cygwin AT sourceware DOT cygnus DOT com
Subject: ld bss bug mixing in msvc object?
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

I'm using cygwin 1.1.4, and I've run into what looks like a problem
linking a msvc object, resulting in collision of objects in the bss.

This program shows that global integers(even those initialized to 0) in
the bss have non-zero values at program run time:

Everything works fine if both files are compiled with cygwin gcc, and
the resultant binary has a much bigger .bss section.
In the mixed binary(where the problem occurs), the .bss looks too small,
and the linker map and instructions to fetch user code globals seem to
reveal conflicting ideas of what lives in it.

=======================================================
Build commands:

gcc -c main.c
cl -c test.c
gcc main.o test.obj
=======================================================
main.c:

extern int noinit_int;
extern int zero_int;
extern int nonzero_int;
void foo();

int main()
{
  foo();
  return 0;
}
=======================================================
test.c:

#include <stdio.h>

int noinit_int;
int zero_int = 0;
int nonzero_int = 1;

static int static_noinit_int;
static int static_zero_int = 0;
static int static_nonzero_int = 1;


void foo()
{
  printf("static_noinit_int  = %d\n"
	 "static_zero_int    = %d\n"
	 "static_nonzero_int = %d\n",
	 static_noinit_int,
	 static_zero_int,
	 static_nonzero_int);

  printf("noinit_int = %d\n"
	 "zero_int = %d\n"
	 "nonzero_int = %d\n",
	 noinit_int,
	 zero_int,
	 nonzero_int);
  return;
}
=======================================================
From the link map:

.bss            0x00403000       0x10
                0x00403000                __bss_start__=.
 *(.bss)
 .bss           0x00403000        0xc
/usr/lib/libcygwin.a(_cygwin_crt0_common.o)
                0x00403004                environ
                0x00403008                _fmode
                0x00403000                _impure_ptr
 *(COMMON)
 COMMON         0x0040300c        0x4 test.obj
                                  0x0 (size before relaxing)
                0x0040300c                noinit_int
                0x00403010                __bss_end__=.

The bss is only 0x10, which seems to be too small. If this program is
built solely using cygwin gcc, the bss is 0x2c, and the behaviour is
correct.

The code for the first call to printf shows that the msvc compiled
global integers reside at the same addresses in the bss as
_impure_ptr(0x403000) and _fmode(0x4030008):

  401063:	a1 08 20 40 00       	mov    0x402008,%eax
  401068:	50                   	push   %eax
  401069:	8b 0d 08 30 40 00    	mov    0x403008,%ecx
  40106f:	51                   	push   %ecx
  401070:	8b 15 00 30 40 00    	mov    0x403000,%edx
  401076:	52                   	push   %edx
  401077:	68 0c 20 40 00       	push   $0x40200c
  40107c:	e8 7f 00 00 00       	call   401100 <_printf>

Does anyone know why this has happened and how to avoid it (given that I
don't have a choice about using certain msvc objects). Is there some
different way I can do the final link to circumvent the problem?
Has anyone run into this before?

Also, if there's a more appropriate list for this, I'll be glad to go
there. The archives do show occasional msvc interop topics though.
Thanks,

Nigel

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe AT sourceware DOT cygnus DOT com