Re: How to stop --gc-sections nukeing all sections?

[greyham at research dot canon dot com dot au (Graham Stoney)]

Ian Lance Taylor writes:
> There is plenty of undocumented stuff in the binutils, but this one
> actually is documented in ld.texinfo.

Please accept my humble appologies.  I really did _try_ to RTFM; turned out
info was giving me an old manual by mistake, not the new one from my install.
:-(

>    For example, arch/ppc/kernel/process.c has functions in the order:
> 
>        kernel_stack_top
>        task_top
>        dump_fpu
>        enable_kernel_fp
>        etc
> 
>    But in the output map, they're in the order:
> 
>        etc
>        c00077a8 T enable_kernel_fp
>        c00077d0 T dump_fpu
>        c0007820 T task_top
>        c0007828 T kernel_stack_top

> Why do you care about the order?

The kernel uses a nasty ha^H^H^H^H^H^H^H^Hneat trick to trap bad user space
accesses. This relies on incrementally building up two tables containing
references to instructions which attempt user space accesses, in sections
named .fixup and __ex_table sections. These tables must be ordered in the same
order as the code they refer to, because a binary search is done on the
__ex_table and this search requires that the entries are in ascending order.

> What does your linker script look like?  Do you put .text.* in the
> .text section?  What order are the sections in the input file?

Yes, I've added .text.* to my .text output section.  Using my example of
process.c above, the section for each function in both the assembler file and
object file are in the same order as the functions appear in the .c file.
They're only reversed in the linker output, and the reversal happens
regardless of whether --gc-sections is specified. It's something about having
each function in its own .text.__FUNCTION__ section which causes it...

> It's possible that the linker will tend to reverse the order of input
> sections which are not mentioned in the linker script and which thus
> cause their own output section to be created.  I'm not sure.

Is it possible that it's reversing the sections when matched by a wildcard
entry like *(.text.*)?  The objects themselves are being linked in the order
on the command line, but the sections within each object are being reversed.
Is there any other linker feature which can cause input sections to be
reversed?  Any idea where I would look in the ld code to check? (So many
questions, sorry!)

>                                                               I would
> normally expect the linker to add explicitly named input sections to
> output sections in the order in which they appear in the input files.

Me too!  In fact, I expected it whether they were explicitly named or matched
via a wildcard or whatever.

> If you look at the linker map, you will see the mapping of input
> sections to output sections.

Sure, here's the relevant section from the map file:

 .text.enable_kernel_fp
                0xc0007110       0x28 arch/ppc/kernel/kernel.o
                0xc0007110                enable_kernel_fp
 .text.dump_fpu
                0xc0007138       0x50 arch/ppc/kernel/kernel.o
                0xc0007138                dump_fpu
 .text.task_top
                0xc0007188        0x8 arch/ppc/kernel/kernel.o
                0xc0007188                task_top
 .text.kernel_stack_top
                0xc0007190        0x8 arch/ppc/kernel/kernel.o
                0xc0007190                kernel_stack_top

If anyone else could shed light on this, I'd be eternally grateful. Well, at
least for the next few hours or so!

Regards,
Graham
-- 
Graham Stoney
Principal Hardware/Software Engineer
Canon Information Systems Research Australia
Ph: +61 2 9805 2909  Fax: +61 2 9805 2929