From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 53154 invoked by alias); 28 Sep 2018 14:31:25 -0000 Mailing-List: contact gnu-gabi-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Post: List-Help: List-Subscribe: Sender: gnu-gabi-owner@sourceware.org Received: (qmail 52989 invoked by uid 89); 28 Sep 2018 14:31:24 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Checked: by ClamAV 0.100.1 on sourceware.org X-Virus-Found: No X-Spam-SWARE-Status: No, score=0.1 required=5.0 tests=AWL,BAYES_00,KAM_LAZY_DOMAIN_SECURITY,RDNS_DYNAMIC,TVD_RCVD_IP autolearn=no version=3.3.2 spammy=ccoutant@gmail.com, our X-Spam-Status: No, score=0.1 required=5.0 tests=AWL,BAYES_00,KAM_LAZY_DOMAIN_SECURITY,RDNS_DYNAMIC,TVD_RCVD_IP autolearn=no version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on sourceware.org X-Spam-Level: X-Spam-User: qpsmtpd, 2 recipients X-HELO: brightrain.aerifal.cx Received: from 216-12-86-13.cv.mvl.ntelos.net (HELO brightrain.aerifal.cx) (216.12.86.13) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 28 Sep 2018 14:31:23 +0000 Received: from dalias by brightrain.aerifal.cx with local (Exim 3.15 #2) id 1g5tmq-0000dl-00; Fri, 28 Sep 2018 14:30:32 +0000 Date: Mon, 01 Jan 2018 00:00:00 -0000 From: Rich Felker To: "H.J. Lu" Cc: Cary Coutant , Carlos O'Donell , Florian Weimer , Szabolcs Nagy , Jan Beulich , Binutils , gnu-gabi@sourceware.org Subject: Re: RFC: Add SHT_GNU_PHDRS Message-ID: <20180928143032.GV17995@brightrain.aerifal.cx> References: <5BAC7D6802000078001EC6D1@prv1-mh.provo.novell.com> <87pnwzuz8r.fsf@oldenburg.str.redhat.com> <20180927103539.GJ10209@port70.net> <87va6rqfg6.fsf@oldenburg.str.redhat.com> <87r2hfqes1.fsf@oldenburg.str.redhat.com> <73bd396c-43be-2922-fce4-17ee835d862e@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-SW-Source: 2018-q3/txt/msg00030.txt.bz2 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 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