Re: ld -r frustration

[Richard Earnshaw <rearnsha at gcc dot gnu dot org>]

On Thu, 2004-07-29 at 13:14, Alan Modra wrote:
> On Thu, Jul 29, 2004 at 10:03:39AM +0100, Richard Earnshaw wrote:
> > On Thu, 2004-07-29 at 03:31, Alan Modra wrote:
> > 
> > > Incidentally, one of the nasty effects of ld -r on any arch is the fact
> > > that it can reorder code.  eg. If compiling with -ffunction-sections,
> > > all static functions called "setup" in different files will be grouped
> > > into the one section.  This loses code locality and can affect cache
> > > performance.
> > 
> > I would expect that to happen on a normal link too.
> 
> No, it doesn't, at least not for sections handled by a properly written
> linker script.  Here's a typical .text output section spec for a final
> link:
> 
>   .text :
>   {
>     *(.text .stub .text.* .gnu.linkonce.t.*)
>     KEEP (*(.text.*personality*))
>     /* .gnu.warning sections are handled specially by elf32.em.  */
>     *(.gnu.warning)
>   }
> 
> This places input sections matching .text, .stub, etc. in the same order
> as they are found in the linker input.  See node "Input Section Basics"
> in ld.info.

Ah!  OK, I think I understand.  So we only coalesce sections with the
same name, and that changes the order.  Sounds like another reason to me
why we shouldn't be doing section coalescing during ld -r.

R.