public inbox for
 help / color / mirror / Atom feed
From: Bevin Hansson <>
To: "" <>
Cc: "" <>,
	"" <>
Subject: ld: provide /PASSTHRU/ section rule to avoid orphan warnings?
Date: Fri, 8 Mar 2024 08:24:22 +0000	[thread overview]
Message-ID: <> (raw)


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

             reply	other threads:[~2024-03-08  8:24 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-03-08  8:24 Bevin Hansson [this message]
  -- 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

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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).