From: Cary Coutant <ccoutant@gmail.com>
To: "Carlos O'Donell" <carlos@redhat.com>
Cc: Florian Weimer <fweimer@redhat.com>,
"H.J. Lu" <hjl.tools@gmail.com>,
nsz@port70.net, JBeulich@suse.com, Rich Felker <dalias@libc.org>,
Binutils <binutils@sourceware.org>,
gnu-gabi@sourceware.org
Subject: Re: RFC: Add SHT_GNU_PHDRS
Date: Mon, 01 Jan 2018 00:00:00 -0000 [thread overview]
Message-ID: <CAJimCsG0SSDPHhHapZfK97CU45AQsXgkdH02mHcM1H1S9ic8ug@mail.gmail.com> (raw)
In-Reply-To: <73bd396c-43be-2922-fce4-17ee835d862e@redhat.com>
> > I'm now under the impression that the bits that are PT_LOAD'ed all need
> > to be covered by (allocated) sections. A zero-sized section doesn't
> > cover anything, so it doesn't address this requirement of the ELF
> > specification.
>
> I agree. What we did in the past by relying on phdrs to be accidentally
> in the first PT_LOAD segment always irked me as bad design.
>
> If we need access to program header we need clear semantics for doing so,
> not hackish kludges to force the linker to get it onto a page that also
> happened to be mapped. This is just poor engineering on our part.
It seems to me that the kernel loader should make the program headers
available to the dynamic loader through the aux vector, whether
they're part of a PT_LOAD segment or not. That should be part of the
psABI. The gABI clearly requires that the dynamic loader has access to
the program headers (e.g., it needs to find PT_DYNAMIC), but it
doesn't care how the implementation accomplishes that.
-cary
next prev parent reply other threads:[~2018-09-27 22:35 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-01-01 0:00 H.J. Lu
2018-01-01 0:00 ` Carlos O'Donell
2018-01-01 0:00 ` H.J. Lu
2018-01-01 0:00 ` Florian Weimer
2018-01-01 0:00 ` Jan Beulich
2018-01-01 0:00 ` Florian Weimer
2018-01-01 0:00 ` Szabolcs Nagy
2018-01-01 0:00 ` H.J. Lu
2018-01-01 0:00 ` Florian Weimer
2018-01-01 0:00 ` H.J. Lu
2018-01-01 0:00 ` Florian Weimer
2018-01-01 0:00 ` Carlos O'Donell
2018-01-01 0:00 ` Cary Coutant [this message]
2018-01-01 0:00 ` H.J. Lu
2018-01-01 0:00 ` Rich Felker
2018-01-01 0:00 ` H.J. Lu
2018-01-01 0:00 ` Carlos O'Donell
2018-01-01 0:00 ` H.J. Lu
2018-01-01 0:00 ` Carlos O'Donell
2018-01-01 0:00 ` Michael Matz
2018-01-01 0:00 ` Florian Weimer
2018-01-01 0:00 ` Michael Matz
2018-01-01 0:00 ` Florian Weimer
2018-01-01 0:00 ` Cary Coutant
[not found] ` <CAORpzuOWtHeqBLEE+MMN4-TZyp6Z1r-MdmyNv7Zj-BhxMstr=g@mail.gmail.com>
2018-01-01 0:00 ` H.J. Lu
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=CAJimCsG0SSDPHhHapZfK97CU45AQsXgkdH02mHcM1H1S9ic8ug@mail.gmail.com \
--to=ccoutant@gmail.com \
--cc=JBeulich@suse.com \
--cc=binutils@sourceware.org \
--cc=carlos@redhat.com \
--cc=dalias@libc.org \
--cc=fweimer@redhat.com \
--cc=gnu-gabi@sourceware.org \
--cc=hjl.tools@gmail.com \
--cc=nsz@port70.net \
/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).