public inbox for binutils@sourceware.org
 help / color / mirror / Atom feed
From: Nick Clifton <nickc@redhat.com>
To: Kees Cook <keescook@chromium.org>, binutils@sourceware.org
Cc: maskray@google.com
Subject: Re: ld: provide /PASSTHRU/ section rule to avoid orphan warnings?
Date: Mon, 4 Sep 2023 13:12:18 +0100	[thread overview]
Message-ID: <8b17facc-30b7-ab24-efdd-6d094a57298d@redhat.com> (raw)
In-Reply-To: <202308291330.05609E535@keescook>

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


  reply	other threads:[~2023-09-04 12:12 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 [this message]
2023-10-11 17:23   ` Kees Cook
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:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

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

  git send-email \
    --in-reply-to=8b17facc-30b7-ab24-efdd-6d094a57298d@redhat.com \
    --to=nickc@redhat.com \
    --cc=binutils@sourceware.org \
    --cc=keescook@chromium.org \
    --cc=maskray@google.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

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