delorie.com/archives/browse.cgi | search |
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 |
From: | Tony Kimball <alk AT pobox DOT com> |
MIME-Version: | 1.0 |
Message-ID: | <15132.15459.386580.755198@spanky.love.edu> |
Date: | Mon, 4 Jun 2001 20:56:51 -0500 |
X-Face: | \h9Jg:Cuivl4S*UP-)gO.6O=T]]@ncM*tn4zG);)lk#4|lqEx=*talx?.<li^!8ecK]}3L- |
6`ZQW3}kxy*5]B<KA"&iBl58"/$W-0PP`B7c%'XczR)8T0VN47L`rQlu8qBIX4TJ|v'D%:k7GO%v4A | |
Os>Gk,dMQU2)ptPC17cpBzm(l'M|H8BUF1&]dDCxZ.c~Wy6-j,^V1E(NtX$FpkkdnJixsJHE95JlhO | |
5\M3jh'YiO7KPCn0~W`Ro44_TB@&JuuqRqgPL'0/{):7rU-%.*@/>q?1&Ed | |
Reply-To: | alk AT pobox DOT com |
To: | java AT gcc DOT gnu DOT org |
Cc: | cygwin AT cygwin DOT com |
Subject: | boehm-gc .comm problem |
X-Mailer: | VM 6.89 under 21.1 (patch 14) "Cuyahoga Valley" XEmacs Lucid |
X-MIME-Autoconverted: | from base64 to 8bit by delorie.com id VAA18344 |
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.
webmaster | delorie software privacy |
Copyright © 2019 by DJ Delorie | Updated Jul 2019 |