From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 127103 invoked by alias); 28 Sep 2018 13:28:10 -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 127071 invoked by uid 89); 28 Sep 2018 13:28:10 -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=-1.9 required=5.0 tests=BAYES_00,SPF_PASS autolearn=ham version=3.3.2 spammy=H*f:sk:87lg7ll, H*i:sk:87lg7ll, route X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,SPF_PASS autolearn=ham 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: mx1.suse.de Received: from mx2.suse.de (HELO mx1.suse.de) (195.135.220.15) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 28 Sep 2018 13:28:08 +0000 X-Virus-Scanned: by amavisd-new at test-mx.suse.de Received: from relay2.suse.de (unknown [195.135.220.254]) by mx1.suse.de (Postfix) with ESMTP id 97792B058; Fri, 28 Sep 2018 13:28:06 +0000 (UTC) Date: Mon, 01 Jan 2018 00:00:00 -0000 From: Michael Matz To: Florian Weimer cc: "H.J. Lu" , Szabolcs Nagy , Jan Beulich , Rich Felker , Binutils , gnu-gabi@sourceware.org Subject: Re: RFC: Add SHT_GNU_PHDRS In-Reply-To: <87lg7llr99.fsf@oldenburg.str.redhat.com> Message-ID: References: <87tvmbv8hp.fsf@oldenburg.str.redhat.com> <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> <87lg7llr99.fsf@oldenburg.str.redhat.com> User-Agent: Alpine 2.21 (LSU 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-IsSubscribed: yes X-SW-Source: 2018-q3/txt/msg00028.txt.bz2 Hi, On Fri, 28 Sep 2018, Florian Weimer wrote: > > 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? Maybe. > That should give us additional feedback whether this reading of the > specification is correct. Well, at least the part about sections being purely optional is undeniably true. The section headers themself were never part of the loaded image (nor part of any section for that matter). Now the but: I would agree that it would be nice if all file contents would be covered by some section if section headers are in the file at all, simply because the named sections are easier for humans to deal with than numbered program headers, so that their use in tools (like e.g. readelf -x) is comfortable. But that's independend and outside of what's required by ELF. If we go down that route then we should go the full way and cover the ELF header, the program headers and the section headers with sections as well. I don't see why they would need their own type though, PROGBITS is just fine. And again, all that would be optional and a pure QoI issue. Ciao, Michael.