public inbox for gnu-gabi@sourceware.org
 help / color / mirror / Atom feed
From: Carlos O'Donell <carlos@redhat.com>
To: Florian Weimer <fweimer@redhat.com>, "H.J. Lu" <hjl.tools@gmail.com>
Cc: 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: <73bd396c-43be-2922-fce4-17ee835d862e@redhat.com> (raw)
In-Reply-To: <87r2hfqes1.fsf@oldenburg.str.redhat.com>

On 9/27/18 8:57 AM, Florian Weimer wrote:
> * H. J. Lu:
> 
>> On Thu, Sep 27, 2018 at 5:42 AM, Florian Weimer <fweimer@redhat.com> wrote:
>>> * H. J. Lu:
>>>
>>>> On Thu, Sep 27, 2018 at 3:35 AM, Szabolcs Nagy <nsz@port70.net> wrote:
>>>>> an alloc .phdr section covering the program headers solves
>>>>> this problem. if sections are not required for segments
>>>>> then simply the linker should ensure that there is always
>>>>> a load segment covering the program headers, possibly
>>>>> without containing any sections, however elf says
>>>>> "An object file segment contains one or more sections".
>>>>>
>>>>> i don't understand why a zero-size section is enough, what
>>>>> if phdr > pagesize? will that get covered by the load
>>>>> segment that is created for the zero-size section?
>>>>
>>>> Linker must keep this zero-size section in output and
>>>> create a PT_LOAD segment to cover it even if it is
>>>> the only SHF_ALLOC section in the PT_LOAD segment.
>>>
>>> Based on Szabolcs' comment, I don't think the section can be zero-sized.
>>>
>>
>> Why can't we put a zero-size section in a PT_LOAD segment?
>> Of course, we need to change linker to do it.
> 
> 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.

-- 
Cheers,
Carlos.

  parent reply	other threads:[~2018-09-27 13:07 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
     [not found] ` <CAORpzuOWtHeqBLEE+MMN4-TZyp6Z1r-MdmyNv7Zj-BhxMstr=g@mail.gmail.com>
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         ` Florian Weimer
2018-01-01  0:00           ` Cary Coutant
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                 ` Michael Matz
2018-01-01  0:00                   ` Florian Weimer
2018-01-01  0:00                     ` Michael Matz
2018-01-01  0:00                 ` Carlos O'Donell [this message]
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                   ` Cary Coutant
2018-01-01  0:00                     ` H.J. Lu
2018-01-01  0:00                       ` Rich Felker

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=73bd396c-43be-2922-fce4-17ee835d862e@redhat.com \
    --to=carlos@redhat.com \
    --cc=JBeulich@suse.com \
    --cc=binutils@sourceware.org \
    --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).