comm/local/ELF/gas/gcc

comm/local/ELF/gas/gcc

[H.J. Lu]

I am kind of confused by the asm output under x86/ELF:

1. There is a limit of MAX_OFILE_ALIGNMENT in bits for maximum alignment.
   But it only applies to symbols in data, not those in bss/common.
2. __attribute__ ((aligned (n))) doesn't do anything useful if n > 4
  for integer or 8 for double. Should a better MAX_OFILE_ALIGNMENT
  be defined for x86?
3. The x86/ELF gas is kind of strange:

	.local x.2
	.comm   x.2,4,4

and

	.comm  x.2,4,16

mean the same alignment. But I checked as on Sparc/Solaris.

	.local x.2
	.comm   x.2,4,16

and

	.comm  x.2,4,16

have the same alignment. Personally I prefer Solaris. But if most of
ELF/SVR4 as does the same as gas, I guess my opinion doesn't count
much.

I don't know what the correct fixes are. I hope:

1. Increase MAX_OFILE_ALIGNMENT for x86 to 0x1000 or somthing like that.
2. Change gas to work like Solaris.


-- 
H.J. Lu
NYNEX Science and Technology, Inc.			hjl@nynexst.com

Re: comm/local/ELF/gas/gcc

[Ian Lance Taylor]

   From: hjl@nynexst.com (H.J. Lu)
   Date: Tue, 28 Nov 95 1:05:35 EST

   1. There is a limit of MAX_OFILE_ALIGNMENT in bits for maximum alignment.
      But it only applies to symbols in data, not those in bss/common.

The problem would appear to be that gcc defaults to value of
MAX_OFILE_ALIGNMENT to BIGGEST_ALIGNMENT.  For the i386,
BIGGEST_ALIGNMENT is 32 or 64.  It would be reasonable for
config/svr4.h in gcc to set MAX_OFILE_ALIGNMENT to 0x80000000.
However, I don't know what the consequences are of requesting an
alignment larger than BIGGEST_ALIGNMENT.  Is that supposed to work or
not?

   3. The x86/ELF gas is kind of strange:

	   .local x.2
	   .comm   x.2,4,4

   and

	   .comm  x.2,4,16

   mean the same alignment.

This was a gas bug.  It is fixed in the 2.6 release.

Ian