Hi Zuxy,
Is this by design or a bug?
A bug. A gcc bug though, not a binutils one. Have a look at the
assembler
output gcc generates for the definition of "b":
.lcomm _b,16
Which assigns 16 bytes of space, unaligned, in the .bss section. 16
bytes
are assigned, rather than 2 because that is the largest alignment
supported
by the pe-i386 port of gcc. (See assemble_static_space() in
gcc/varasm.c
for this).
What's the intended output of gcc for var then? 16 is 2**4 but
"objdump -h" shows a bss aligned as 2**3.
True, but the 16 in the .lcomm directive is the size reserved for the "_b"
object and not its alignment. (Plus this value comes from the maximum
alignment supported by the pe-i386 port, not the aligned(16) attribute on
the "b" variable. Try changing the alignment to some other value to see
this).
What I think gcc should be outputting for an aligned, local common is
something like this:
.bss
.align <alignment required>
.lcomm <name>, <size>
It looks like the definition of ASM_OUTPUT_LOCAL in
gcc/config/i386/bsd.h
needs to be fixed, or maybe the file should be extended to include a
definition of ASM_OUTPUT_ALIGNED_LOCAL.
But I don't think mingw32 binutils can recognize such patterns even if
gcc produces them.
Why not try out this patch and see if it helps ?
Index: gcc/config/i386/bsd.h
===================================================================
--- gcc/config/i386/bsd.h (revision 137552)
+++ gcc/config/i386/bsd.h (working copy)
@@ -65,6 +65,11 @@
assemble_name ((FILE), (NAME)), \
fprintf ((FILE), ",%u\n", (int)(ROUNDED)))
+#define ASM_OUTPUT_ALIGNED_LOCAL(FILE, NAME, SIZE, ALIGNMENT) \
+( fprintf ((FILE), ".bss\n\t.align %u\n\t.lcomm ", (int) (ALIGNMENT)), \
+ assemble_name ((FILE), (NAME)), \
+ fprintf ((FILE), ",%u\n", (int)(SIZE)))
+
/* This is how to output an assembler line
that says to advance the location counter
to a multiple of 2**LOG bytes. */