public inbox for
 help / color / mirror / Atom feed
* ld: provide /PASSTHRU/ section rule to avoid orphan warnings?
@ 2024-03-08  8:24 Bevin Hansson
  0 siblings, 0 replies; 4+ messages in thread
From: Bevin Hansson @ 2024-03-08  8:24 UTC (permalink / raw)
  To: binutils; +Cc: nickc, keescook


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/ : {

    .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/

/ Bevin

^ permalink raw reply	[flat|nested] 4+ messages in thread
* ld: provide /PASSTHRU/ section rule to avoid orphan warnings?
@ 2023-08-29 20:39 Kees Cook
  2023-09-04 12:12 ` Nick Clifton
  0 siblings, 1 reply; 4+ messages in thread
From: Kees Cook @ 2023-08-29 20:39 UTC (permalink / raw)
  To: binutils; +Cc: maskray


The Linux kernel would like to have a way for the linker to emit sections
without changing their section name, using wildcards. (This is needed
for our efforts towards Function-Granular Kernel Address Space Layout
Randomization[1].) 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".

e.g. if we had something like:


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've opened issues in both binutils[2] and LLVM[3] for this and was
hoping to get some feedback on what's needed to see this implemented.  :)




Kees Cook

^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2024-03-08  8:24 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2024-03-08  8:24 ld: provide /PASSTHRU/ section rule to avoid orphan warnings? Bevin Hansson
  -- strict thread matches above, loose matches on Subject: below --
2023-08-29 20:39 Kees Cook
2023-09-04 12:12 ` Nick Clifton
2023-10-11 17:23   ` Kees Cook

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).