Re: RFC: Add SHT_GNU_PHDRS

[Rich Felker <dalias at libc dot org>]

On Fri, Sep 28, 2018 at 06:42:52AM -0700, H.J. Lu wrote:
> On Thu, Sep 27, 2018 at 3:34 PM, Cary Coutant <ccoutant@gmail.com> wrote:
> >> > 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.
> >
> 
> Dynamic loader has no problem.  The problem is kernel passes
> AT_PHDR to main, which points to the unmmaped address.   We can
> ask for kernel change or make kernel happy.

Kernel change does not help because nobody is obligated to use a new
kernel. Binutils would be producing binaries that don't work on
existing kernels (if the note hack were reverted or if similar changes
were added to other archs without a note hack; right now of course
it's working again).

> My current .note.gnu.property patch only works for x86.   We can
> add
> 
> #define GNU_PROPERTY_PHDRS 3
> 
> so that it can be used for all targets.

What would this do?

Rich