linux-mips
[Top] [All Lists]

Re: MIPS section alignment of object file

To: robert song <robertsong.linux@gmail.com>
Subject: Re: MIPS section alignment of object file
From: Ralf Baechle <ralf@linux-mips.org>
Date: Fri, 22 Feb 2008 12:29:26 +0000
Cc: linux-mips@linux-mips.org
In-reply-to: <3e004f8e0802210812k723a11f5ve9fa816d83bb082b@mail.gmail.com>
Original-recipient: rfc822;linux-mips@linux-mips.org
References: <3e004f8e0802210812k723a11f5ve9fa816d83bb082b@mail.gmail.com>
Sender: linux-mips-bounce@linux-mips.org
User-agent: Mutt/1.5.17 (2007-11-01)
On Fri, Feb 22, 2008 at 01:12:01AM +0900, robert song wrote:

> But in other architectures like arm, .data section is aligned to 4
> bytes alignment,
> and  now I test the object file generated by gas, and found that the
> size of .data section sometimes is a little bigger than the situation
> of 4 bytes alignments because of the amount of padding.
> 
> There are some comments in the tc-mips.c as bellows:
>          On a native system other than VxWorks, sections must be aligned
>        to 16 byte boundaries.  When configured for an embedded ELF
>        target, we don't bother.
> 
> I want to know whether some mips architecture requires that the
> sections of elf object file specifies to be aligned to 16 bytes,  or
> else 16-bytes alignment will get a good performance than other
> alignments just like 4 bytes????
> 
> I recompiled  the binutils by changing the alignment to 4 bytes, and
> compiled some
> test files, and ran on my mips target(TX4937). There is no problem.
> 
> I am really puzzled and any help will be appreciated.

The minimum alignment technically required is the largest alignment of
any type contained in a section.  Due to the possibility of relocatable
links the assembler can't know what the largest aligment is, so it has
to make a reasonable guess which would be 8 bytes, the size of a double
floating point.  For performance reasons an alignment of the size of a
primary cache line (typically 32 byte these days but could be as much as
128 bytes) could make sense.

  Ralf

<Prev in Thread] Current Thread [Next in Thread>