Mailing-List: contact cygwin-help AT sourceware DOT cygnus DOT com; run by ezmlm List-Subscribe: List-Archive: List-Post: List-Help: , 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 Content-Type: text/plain; charset="iso-8859-1" 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: X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: boehm-gc .comm problem Thread-Index: AcDtYYQJAPsfij8BQdqp6YGW4HR39gAB0DZQ From: "Robert Collins" To: , Cc: Content-Transfer-Encoding: 8bit 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