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

[Bevin Hansson <bevin.hansson@ericsson.com>]

Hi,

We also have a need for a feature like this in lld. There doesn't seem to be
much more activity on this, so I'll offer my two cents on the topic.

> 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 ?

I think that the wildcard flag idea would cover our use case; not the more
specific option, though. However, I think that having the linker script feature
is a lot more flexible. It lets you express that sections in certain files
should be preserved, but later match everything of that section:

    /PASSTHRU/ : {
      foo.o(.bar.x);
    }

    .bar : {
      *(.bar*);
    }

This would prevent the matching of the .bar.x section from that particular
file (since it has already been matched by the /PASSTHRU/), but would still
allow you to globally match anything with that prefix afterwards. This wouldn't
be possible with the option approach, since it would only take effect at the
end after all of the matching is already done.

However, this isn't the same behavior as what Kees' mentioned:
> - Therefore for ordering purposes the /PASSTHRU/ section behaves like
>   it is "last" in the linker script, regardless of its actual position.

But maybe this is simpler to implement in ld than in lld? For the time being I
can't really see my above example as a use case for us specifically, but the
need might pop up in the future. I think it's a bit odd to have it in the
linker script and then not have it behave as other 'special' output sections
do, like /DISCARD/. That wouldn't be what I'd expect as a user.

Regardless, I do agree with Kees' point that having this kind of logic in
the linker invocation rather than the linker script is a bit cumbersome.

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

I think this is the reasonable behavior. The order of matches in the block
shouldn't matter in the same way that the order doesn't matter in a /DISCARD/
block.

/ Bevin