public inbox for
 help / color / mirror / Atom feed
From: Kees Cook <>
To: Nick Clifton <>
Subject: Re: ld: provide /PASSTHRU/ section rule to avoid orphan warnings?
Date: Wed, 11 Oct 2023 10:23:45 -0700	[thread overview]
Message-ID: <202310111006.5195BE8FF@keescook> (raw)
In-Reply-To: <>

On Mon, Sep 04, 2023 at 01:12:18PM +0100, Nick Clifton wrote:
> Hi Kees,

Hi! Thanks for the looking at this and sorry I got distracted until now
to reply to this. :)

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

It's certainly possible, but it's "extra work" that really doesn't seems
to be done in the right place. "Make a list of all section names that
are in the files that the linker is about to read where it finds the
same list." :)

More specifically, when this is done, we end up with a 65,000 line linker
script, and the link stage (which normally takes a handful of seconds)
ends up taking something like 10 minutes -- I assume the linker is doing
repeated linear searches. So while that pathological condition could
certainly be found it illustrates to me that listing all sections
explicitly is going down the wrong solution path.

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

Yeah, that could work, for sure. My instinct is that this would become
ungainly over time, though, since we'd now be splitting section naming
logic between the linker script and the command-line invocation, which
we've never had to do before: all the section name patterns we're
dealing with are only in the linker script right now. And as we start
adding more than just .text.* to the pass-through list, we'll end up
having to make the linker invocation more and more complex.

Right now all of the section patterns are built with various macros and
conditions in the linker script. Having to bring that out into the
invocation seems like poor ergonomics.

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

I assumed that it wouldn't be too hard since the orphan handling already
does what we want: it just copies an input section to an identically
named output section. I figured the patterns loaded from a "/PASSTHRU/"
list would just be used to silence the orphan warning.

> 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 and
> and b.o containing and  In the resulting output, what
> order should the sections appear ?
> (assuming that a.o comes before b.o on the linker command line) or:
> (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.

Right -- I think the ordering is just whatever order the linker
encounters the sections. The orphan handling appears to do this already
(though it does seem to attempt to "group" similar stuff, but that's
heuristic we don't depend on at all).

Our use of /PASSTHRU/ very much doesn't care about ordering since we're
literally going to randomize the order of those sections at load time
anyway. :) But yes, I see why you'd want some kind of declaration of
intended behavior.

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

Agreed! It was Fangrui Song who suggested I make sure LD.BFD was
involved in the discussion, as I originally had just asked about LLD.
(I'd wanted to gauge how difficult this feature would be.)

So, as a strawman, how about this:

- When warning about orphan sections, anything matching a /PASSTHRU/
  rule is silenced (as it is now an 'expected' pass-through.
- Therefore for ordering purposes the /PASSTHRU/ section behaves like
  it is "last" in the linker script, regardless of its actual position.

Kees Cook

  reply	other threads:[~2023-10-11 17:23 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-08-29 20:39 Kees Cook
2023-09-04 12:12 ` Nick Clifton
2023-10-11 17:23   ` Kees Cook [this message]
2024-03-08  8:24 Bevin Hansson

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 \
    --in-reply-to=202310111006.5195BE8FF@keescook \ \ \ \ \

* 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).