public inbox for gnu-gabi@sourceware.org
 help / color / mirror / Atom feed
From: Cary Coutant <ccoutant@gmail.com>
To: "H.J. Lu" <hjl.tools@gmail.com>
Cc: Michael Matz <matz@suse.de>, Rich Felker <dalias@libc.org>,
	"Carlos O'Donell" <carlos@redhat.com>,
		Florian Weimer <fweimer@redhat.com>,
	nsz@port70.net, Jan Beulich <JBeulich@suse.com>,
		Binutils <binutils@sourceware.org>,
	gnu-gabi@sourceware.org
Subject: Re: RFC: Add GNU_PROPERTY_NEED_PHDRS
Date: Mon, 01 Jan 2018 00:00:00 -0000	[thread overview]
Message-ID: <CAJimCsHSBKqrMz_0bLeb7s0D-b18eOzr=5zs7rOFXUwJDeiB0g@mail.gmail.com> (raw)
In-Reply-To: <CAMe9rOqfXXtUF=3H-TtcPaB5_emjbzV7gQ7MsXDj4iiJr1wC-Q@mail.gmail.com>

> 1. Linker kernel passes AT_PHDR to main and assumes that AT_PHDR
> is in a PT_LOAD segment.

s/Linker/Linux/

One could argue that this is the real (and only) problem. If it's
going to pass a pointer to the program headers, the kernel should make
sure that the headers are mapped, whether or not they're part of a
PT_LOAD segment.

Even with no-separate-code, or with a read-only segment before the
text, the inclusion of the program headers in the first PT_LOAD
segment is merely a happy accident -- it's a side effect of way the
linker rounds segment boundaries down and up to page boundaries, and
depends entirely on the property that the first PT_LOAD segment falls
within the first page of the executable file. If, for some reason, the
linker were to place additional non-loadable stuff between the headers
and the text (e.g., symbol tables, section tables), this could fail.
In fact, if the program headers themselves happen to be so large as to
spill over onto the second page of the file, the first PT_LOAD segment
would not necessarily include the first page of the file.

Now, I understand that fixing the Linux kernel to map the headers even
if they're not part of a PT_LOAD segment isn't a practical
alternative. That leads to...

> 2. gABI doesn't require phdrs in a PT_LOAD segment.

It doesn't belong in the gABI, as the mechanics of making the program
header information available to the dynamic loader and the running
program are processor- and OS-specific.

Since this is a Linux-specific issue, not an architecture-specific
one, we really should put this in an osABI document rather than a
psABI document. I suppose the LSB serves as such. Or maybe the gnu ABI
document?

> 3. Ld won't create a PT_LOAD segment just to hold phdrs.

You seem to be breezing right past the idea of doing exactly this.
Why? The scripting language already allows you to declare which
segment should include FILEHDR and PHDRS. For -z separate-code, why
not use a default linker script with something like the following?

     PHDRS
     {
       headers PT_PHDR PHDRS ;
       interp PT_INTERP ;
       header_seg PT_LOAD FILEHDR PHDRS ;
       text PT_LOAD ;
       data PT_LOAD ;
       dynamic PT_DYNAMIC ;
     }

> 4. With -z separate-code, linker won't put any non-code in a PF_X PT_LOAD
> segment.
>
> When there are only PF_X PT_LOAD segments, phdrs isn't in any PT_LOAD
> segment.
>
> You are looking for a solution to create a PT_LOAD segment just to hold phdrs.
> I have investigated it.  It is very intrusive.  My solution, which you
> called a hack,
> is to add a read-only SHF_ALLOC section so that a PT_LOAD segment will
> be created by ld to hold phdrs when there is only PF_X PT_LOAD segments
> otherwise.

How is it intrusive? If the above linker script doesn't do the job,
isn't that a bug anyway?

And, really, there's no denying that adding an otherwise-unnecessary
note section -- just to get us back into the realm of "it works by
happy accident" -- is a pure hack.

-cary

  reply	other threads:[~2018-10-02 21:06 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-01-01  0:00 H.J. Lu
2018-01-01  0:00 ` Michael Matz
2018-01-01  0:00   ` H.J. Lu
2018-01-01  0:00     ` Michael Matz
2018-01-01  0:00       ` H.J. Lu
2018-01-01  0:00         ` Michael Matz
2018-01-01  0:00           ` H.J. Lu
2018-01-01  0:00             ` Michael Matz
2018-01-01  0:00               ` H.J. Lu
2018-01-01  0:00                 ` Cary Coutant [this message]
2018-01-01  0:00                   ` Alan Modra
2018-01-01  0:00                     ` Cary Coutant
2018-01-01  0:00                       ` Alan Modra
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                                 ` Alan Modra

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='CAJimCsHSBKqrMz_0bLeb7s0D-b18eOzr=5zs7rOFXUwJDeiB0g@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=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).