This is the mail archive of the cygwin@cygwin.com mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

RE: boehm-gc .comm problem


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@pobox.com]
> Sent: Tuesday, June 05, 2001 11:57 AM
> To: java@gcc.gnu.org
> Cc: cygwin@cygwin.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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]