From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19831 invoked by alias); 4 Oct 2018 17:17:32 -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 19810 invoked by uid 89); 4 Oct 2018 17:17:31 -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, H*i:sk:guP50Ua, H*f:sk:guP50Ua, ccoutantgmailcom 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; Thu, 04 Oct 2018 17:17:30 +0000 Received: from dalias by brightrain.aerifal.cx with local (Exim 3.15 #2) id 1g87Eu-0003VF-00; Thu, 04 Oct 2018 17:16:40 +0000 Date: Mon, 01 Jan 2018 00:00:00 -0000 From: Rich Felker To: "H.J. Lu" Cc: Cary Coutant , Alan Modra , Michael Matz , Carlos O'Donell , Florian Weimer , Szabolcs Nagy , Jan Beulich , Binutils , gnu-gabi@sourceware.org Subject: Re: RFC: Add GNU_PROPERTY_NEED_PHDRS Message-ID: <20181004171640.GE17110@brightrain.aerifal.cx> References: <20181003075416.GD3179@bubble.grove.modra.org> <20181004021457.GE3179@bubble.grove.modra.org> 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-q4/txt/msg00014.txt.bz2 On Thu, Oct 04, 2018 at 09:33:43AM -0700, H.J. Lu wrote: > On Thu, Oct 4, 2018 at 8:10 AM Cary Coutant wrote: > > > > > If you specify PHDRS in a script, ld uses exactly those program > > > headers, and I believe it should continue to operate that way. So to > > > add PT_GNU_EH_FRAME, say, when an executable has .eh_frame_hdr, you'd > > > need a script with PT_GNU_EH_FRAME specified in PHDRS. And another > > > without PT_GNU_EH_FRAME when the executable doesn't have > > > .eh_frame_hdr. That soon becomes impractial considering the number of > > > optional headers, requiring auto-generation of the PHDRS script > > > snippet. > > > > Oh, I see. Yeah, that does make it impractical. > > > > Still, I'd like to understand why HJ claims it's intrusive to have ld > > create a PT_LOAD segment for the headers. I haven't tried it yet in > > gold (don't support -z separate-code), but it doesn't seem like it > > would be at all difficult or intrusive. > > The linker part is relatively easy. The problems are with strip and > objcopy. They aren't prepared to deal with it. Can you elaborate on what would go wrong with them? AIUI they can't remove anything from segments; they can only remove non-loaded sections. (I found this out the hard way a long time ago trying to get strip to remove unneeded .eh_frame) Rich