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
next prev parent 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).