Re: What's the meaning of "Algn" in "objdump -h"?

["Zuxy Meng" <zuxy dot meng at gmail dot com>]

Hi Nick,

2008/7/8 Nick Clifton <nickc@redhat.com>:
> Hi Zuxy,
>
>>> Does it mean that uninitialized vars in such objects may get
>>> misaligned when linked together?
>
> Yes.
>
>>> Or the "aligned" attribute takes
>>> effect only with -fno-common under mingw32?
>
> Also yes.
>
>> But for a static var
>>
>> C:\MSYS\home\jimeng>type x.c
>> static short b __attribute__((aligned(16)));
>
>> C:\MSYS\home\jimeng>objdump -h x.o
>
>> Sections:
>> Idx Name          Size      VMA       LMA       File off  Algn
>>  0 .text         00000020  00000000  00000000  0000008c  2**4
>>                 CONTENTS, ALLOC, LOAD, RELOC, READONLY, CODE
>>  1 .data         00000000  00000000  00000000  00000000  2**2
>>                 ALLOC, LOAD, DATA
>>  2 .bss          00000010  00000000  00000000  00000000  2**3
>>                 ALLOC
>>
>> 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.

> 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.

-- 
Zuxy
Beauty is truth,
While truth is beauty.
PGP KeyID: E8555ED6