From: Cary Coutant <ccoutant@gmail.com>
To: Fangrui Song <i@maskray.me>
Cc: Florian Weimer <fw@deneb.enyo.de>,
Binutils <binutils@sourceware.org>,
gnu-gabi@sourceware.org
Subject: Re: [ld] Allow custom sections to be under PT_GNU_RELRO
Date: Tue, 7 Apr 2020 09:37:07 -0700 [thread overview]
Message-ID: <CAJimCsFYvPgxCbcJ7VoD-wzYqC6wXYoY0grXV2T-ziuWxQA5yw@mail.gmail.com> (raw)
In-Reply-To: <20200407061016.dkrfo4c5u37ck5qf@gmail.com>
> For that case, inventing new stuff DT_GNU_RELRO/DT_GNU_RELROSZ is not
> really meaningful. Rich Felker reminded me that this is about how
> segments are mapped/protected. PT_* (the current design) is more
> appropriate.
I disagree with this, but not strongly. I believe that the program
header table entries are for the kernel loader, and the more things we
add there for the dynamic loader means more spam that the kernel
loader has to sift through. Of course, PT_DYNAMIC is needed, but once
we have that, the dynamic loader can find everything else it needs in
the dynamic table. I think PT_xxx_UNWIND probably should have been a
pair of dynamic table entries, too (that might fit in with Rich's
logic).
If I were designing ELF from scratch, I'd be tempted to combine the
program header table and the dynamic table into one, perhaps
partitioning it so that kernel-significant entries all come first.
-cary
prev parent reply other threads:[~2020-04-07 16:37 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <20200328042257.3scmekcyrii527ta@gmail.com>
[not found] ` <87lfnkdcbn.fsf@mid.deneb.enyo.de>
[not found] ` <CAJimCsGoBbMs71vE=+vrnKSQrnjw2ry71z7JFdoTu-nDOjexFA@mail.gmail.com>
[not found] ` <20200407025119.iapvp3gyck7ziilr@gmail.com>
[not found] ` <20200407031817.jyqxtxdgnpqpsp72@gmail.com>
2020-04-07 6:10 ` Fangrui Song
2020-04-07 16:37 ` Cary Coutant [this message]
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=CAJimCsFYvPgxCbcJ7VoD-wzYqC6wXYoY0grXV2T-ziuWxQA5yw@mail.gmail.com \
--to=ccoutant@gmail.com \
--cc=binutils@sourceware.org \
--cc=fw@deneb.enyo.de \
--cc=gnu-gabi@sourceware.org \
--cc=i@maskray.me \
/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).