Mailing-List:	contact cygwin-help AT sourceware DOT cygnus DOT com; run by ezmlm
List-Subscribe:	<mailto:cygwin-subscribe AT sources DOT redhat DOT com>
List-Archive:	<http://sources.redhat.com/ml/cygwin/>
List-Post:	<mailto:cygwin AT sources DOT redhat DOT com>
List-Help:	<mailto:cygwin-help AT sources DOT redhat DOT com>, <http://sources.redhat.com/ml/#faqs>
Sender:	cygwin-owner AT sources DOT redhat DOT com
Delivered-To:	mailing list cygwin AT sources DOT redhat DOT com
Subject:	RE: boehm-gc .comm problem
MIME-Version:	1.0
Date:	Tue, 5 Jun 2001 12:41:34 +1000
content-class:	urn:content-classes:message
X-MimeOLE:	Produced By Microsoft Exchange V6.0.4417.0
Message-ID:	<EA18B9FA0FE4194AA2B4CDB91F73C0EF08F037@itdomain002.itdomain.net.au>
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
Thread-Topic:	boehm-gc .comm problem
Thread-Index:	AcDtYYQJAPsfij8BQdqp6YGW4HR39gAB0DZQ
From:	"Robert Collins" <robert DOT collins AT itdomain DOT com DOT au>
To:	<alk AT pobox DOT com>, <java AT gcc DOT gnu DOT org>
Cc:	<cygwin AT cygwin DOT com>
X-MIME-Autoconverted:	from quoted-printable to 8bit by delorie.com id WAA20719

Might I suggest using pthreads? They are the official threads for
cygwin.

Whilst much of cygwin should operate correctly with win32 threads, it's
not guaranteed. 

The cygwin pthreads is a wrapper around win32 threads, not emulated
threads, so there is little-or-no-performance reason to go with win32
threads.

Rob
 

> -----Original Message-----
> From: Tony Kimball [mailto:alk AT pobox DOT com]
> Sent: Tuesday, June 05, 2001 11:57 AM
> To: java AT gcc DOT gnu DOT org
> Cc: cygwin AT cygwin DOT com
> Subject: boehm-gc .comm problem
> 
> 
> 
> Here's a ball of confusion that I'm hoping a reader can help me
> unwind.  I am inclined to blame the cygwin-target binutils gas for
> this problem.  However, I'd like to work-around this for the nonce by
> not using commons.  Questions: Would this be an ABI problem?  Am I on
> the right track in blaming gas?
> 
> With a cygwin target, linux host, win32 threads, building boehm-gc,
> allchblk.c, I get stuff like this:
> 
> 	.comm	_A, 16	 # 4
> 	.comm	_A, 32	 # 24
> 	.comm	_A, 16	 # 4
> 
> which results in stuff like this:
> 
>   /usr/home/alk/tmp/ccZeLBab.s: Assembler messages:
> 
>   /usr/home/alk/tmp/ccZeLBab.s:4478: Error: Length of .comm 
> "_A" is already 16. Not changed to 32.
> 
> 
> which is inconsistent with this (gas texinfo):
> 
>  .comm symbol , length   
> 
>  .comm declares a named common area in the bss section. Normally
>  reserves memory addresses for it during linking, so no partial
>  program defines the location of the symbol. Use .comm to tell that
>  it must be at least length bytes long.  will allocate space for each
>  .comm symbol that is at least as long as the longest .comm request
>  in any of the partial programs linked. length is an absolute
>  expression.
> 
> The target linux version does not emit any .comms.  My reasoning is
> that existing cygwin libs must use .comm in such 
> circumstances, in order to
> get consistent storage for globals.
> 
> If anyone can recommend pertinent reading, I would be appreciative.
> 

--
Want to unsubscribe from this list?
Check out: http://cygwin.com/ml/#unsubscribe-simple

- Raw text -