ld: provide /PASSTHRU/ section rule to avoid orphan warnings?

[Nick Clifton]

Hi Kees,

> The Linux kernel would like to have a way for the linker to emit sections
> without changing their section name, using wildcards.

I take it that it is hard/impossible for the kernel build process to know
beforehand what these section names will be ?  If the build process did
know then it could probably use a linker script fragment to ensure that
they were copied through.


> Normally this happens automatically if a section
> doesn't match an existing rule, but then the --orphan-handling=warn
> option will report it. There is currently no way to silence these
> "expected sections".

So one way to address this problem would be to extend the --orphan-handling
option so that it does not emit messages for certain sections.  This has the
advantage of not needing to extend the linker script syntax.  How about
something like --no-warn-orphan=<wildcard> option which could suppress warnings
for matching sections ?  Or --orphan-handling=warn-except-text which would
warn for any unplaced section that is not executable ?


> e.g. if we had something like:
> 
> 	/PASSTHRU/ : {
> 		*(.text.*)
> 	}
> 
> Then stuff like ".text.func1" and ".text.func2" will pass through as-is,
> but something unexpected, like ".other" would still get correctly
> reported by --orphan-handling=warn.

I have a feeling that this solution would be difficult to implement since the
linker script processing is not really set up for generating an unknown number
of output sections from a single clause in the script.  I am not 100% sure of
this though, since I have not actually tried to implement it.

In theory the script extension seems like a good idea, although I do wonder
about section ordering.  For example, suppose a script had this:

   /PASSTHRU/ : { *(.text.*) *(.init.*) }

and then you have two input files - a.o containing .text.a.foo and .init.a.foo
and b.o containing .text.b.foo and .init.b.foo.  In the resulting output, what
order should the sections appear ?

   .text.a.foo
   .init.a.foo
   .text.b.foo
   .init.b.foo

(assuming that a.o comes before b.o on the linker command line) or:

   .text.a.foo
   .text.b.foo
   .init.a.foo
   .init.b.foo

(because the .text.* pattern appears before the .init.* pattern in the linker script)

Or maybe no ordering should be expected and the user gets whatever the linker
decides to do.


Obviously it would be best if LLD and LD.BFD and LD.GOLD all supported the
same solution, so lets see if we can coordinate our response.

Cheers
   Nick