Re: Is it normal that ld promote a section size

[Terry Guo <flameroc at gmail dot com>]

On Tue, Feb 17, 2015 at 11:36 AM, Terry Guo <flameroc@gmail.com> wrote:
> On Mon, Feb 16, 2015 at 2:54 PM, Alan Modra <amodra@gmail.com> wrote:
>> On Mon, Feb 16, 2015 at 11:51:05AM +0800, Terry Guo wrote:
>>> It looks to me that the size of usb_qh is promoted from 0x300(768)
>>> bytes to 0x800(2048) bytes. The section .bss.UBS_EpStatus can prove
>>> this. IMHO this section should start from 0x2000f300 rather than
>>> 0x2000f800. This causes waste of space. Is this normal?
>>
>> Have you looked at the relocatable object files?  I think it likely
>> you'll find your assembler is responsible for adding padding.  If gas,
>> see SUB_SEGMENT_ALIGN.
>>
>> --
>> Alan Modra
>> Australia Development Lab, IBM
>
> Thanks Alan and you are right. It is gas that increased the section
> size. I am trying to figure out why gas do so because nothing in the
> assembly code tell gas to do so. My assembly code is generated with
> gcc flto. If I disable gcc flto, gas won't add padding for the
> assembly code.
>
> BR,
> Terry

Hi Alan,

I had a further study and found this has nothing to do with LTO. It is
something related to -fdata-sections. If use gcc to compile below c
code without option -fdata-sections:

usb_queue_head_t usb_qh[12] __attribute__(aligned(2048));

The global array usb_qh will be treated as a block in bss section and
its size will be regarded as its actual size 0x300 bytes. But if
compiled with option -fdata-sections, it will be treated as an
individual section .bss.usb_qh and then its size will be promoted to
0x800 by gas. I checked SUB_SEGMENT_ALIGN as you suggested, but
couldn't find more detailed information to help me understand this
issue. Do you know the background why gas has to promote the size to
its alignment? Thanks.

BR,
Terry