From: Florian Weimer <fweimer@redhat.com>
To: Michael Matz <matz@suse.de>
Cc: "H.J. Lu" <hjl.tools@gmail.com>, Szabolcs Nagy <nsz@port70.net>,
Jan Beulich <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: <87lg7llr99.fsf@oldenburg.str.redhat.com> (raw)
In-Reply-To: <alpine.LSU.2.21.1809281225090.7867@wotan.suse.de> (Michael Matz's message of "Fri, 28 Sep 2018 12:32:33 +0000 (UTC)")
* Michael Matz:
> On Thu, 27 Sep 2018, Florian Weimer wrote:
>
>> I'm now under the impression that the bits that are PT_LOAD'ed all need
>> to be covered by (allocated) sections.
>
> That is wrong. Szabolcs is reading too much into some careless wording of
> the ELF text that simply tries to convey the idea that usually segments
> contents are the result of some sections combined by the link editor.
> Sections are purely optional in the execution view.
>
> This section hack isn't necessary at all for what we need. The link
> editor merely needs to ensure that the program headers are part of some
> loadable segment, either by placing it not at the start of the file
> (though that would mean the ELF header isn't part of the loaded image,
> which is desirable to have), or by creating such loadble segment if
> necessary.
>
> No gABI extensions are needed.
That would certainly be nice.
Can we try to update the ELF specification to clarify this? That should
give us additional feedback whether this reading of the specification is
correct.
Thanks,
Florian
next prev parent reply other threads:[~2018-09-28 12:51 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 ` 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
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 [this message]
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
2018-01-01 0:00 ` Carlos O'Donell
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=87lg7llr99.fsf@oldenburg.str.redhat.com \
--to=fweimer@redhat.com \
--cc=JBeulich@suse.com \
--cc=binutils@sourceware.org \
--cc=dalias@libc.org \
--cc=gnu-gabi@sourceware.org \
--cc=hjl.tools@gmail.com \
--cc=matz@suse.de \
--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).