public inbox for binutils@sourceware.org
 help / color / mirror / Atom feed
From: Nick Clifton <nickc@redhat.com>
To: Fangrui Song <i@maskray.me>
Cc: Alan Modra <amodra@gmail.com>,
	binutils@sourceware.org,
	Luca Boccassi <luca.boccassi@microsoft.com>
Subject: Re: Output section type (READONLY)
Date: Tue, 1 Feb 2022 11:07:30 +0000	[thread overview]
Message-ID: <c62e6fc5-3464-3598-1353-80e2b3ef3f3f@redhat.com> (raw)
In-Reply-To: <20220201033930.ssqtsoha6jaqzsfs@gmail.com>

Hi Fangrui,

> For READONLY, I am thinking more in line with "whether we need this
> feature at all"... If no input has SHF_WRITE, the output naturally does
> not have SHF_WRITE; if an input has SHF_WRITE, chancing the output to
> non-SHF_WRITE is weird and error-prone.

I do not know if this counts as a *justified* use of READONLY, but it was
used recently in an attempt to add a new feature to Fedora rawhide:

   https://fedoraproject.org/wiki/Changes/Package_information_on_ELF_objects#New_system:_.note.package

The feature used a custom linker script fragment to add a note section
into the executable being created, and this script used the READONLY
keyword:

   SECTIONS
   {
     .note.package (READONLY) : ALIGN(4) {
         BYTE(0x04) BYTE(0x00) BYTE(0x00) BYTE(0x00) /* Length of Owner including NUL */
  [...]
     }
   }
   INSERT AFTER .note.gnu.build-id;

This turned out to be problematic however as gold does not support the
READONLY attribute, nor the INSERT AFTER directive...

Anyway I think that the point here was that was no input section, so
the author needed another way to tell the linker that the output section
should be readonly.

Cheers
   Nick


  reply	other threads:[~2022-02-01 11:07 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-01-29  7:45 Fangrui Song
2022-01-29 16:46 ` Luca Boccassi
2022-01-29 18:51   ` Fangrui Song
2022-01-31 13:33 ` Nick Clifton
2022-02-01  3:39   ` Fangrui Song
2022-02-01 11:07     ` Nick Clifton [this message]
2022-02-01 11:59       ` Luca Boccassi
2022-02-02  7:29         ` Fangrui Song
2022-02-02 16:54           ` Michael Matz
2022-02-02 18:12             ` Luca Boccassi
2022-02-16 17:38               ` Nick Clifton
2022-02-16 19:03                 ` Luca Boccassi
2022-02-17  2:12                 ` Fangrui Song
2022-02-21 23:04                   ` Alan Modra
2022-02-21 23:30                     ` Fangrui Song

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=c62e6fc5-3464-3598-1353-80e2b3ef3f3f@redhat.com \
    --to=nickc@redhat.com \
    --cc=amodra@gmail.com \
    --cc=binutils@sourceware.org \
    --cc=i@maskray.me \
    --cc=luca.boccassi@microsoft.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).