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]

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.

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