This is the mail archive of the
java@gcc.gnu.org
mailing list for the Java project.
boehm-gc .comm problem
- To: java at gcc dot gnu dot org
- Subject: boehm-gc .comm problem
- From: Tony Kimball <alk at pobox dot com>
- Date: Mon, 4 Jun 2001 20:56:51 -0500
- Cc: cygwin at cygwin dot com
- Reply-To: alk at pobox dot com
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.