From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 88600 invoked by alias); 3 Oct 2018 07:54:24 -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 88574 invoked by uid 89); 3 Oct 2018 07:54: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=-3.1 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.2 spammy=H*RU:sk:mail-pl, Hx-spam-relays-external:sk:mail-pl, HX-HELO:sk:mail-pl, H*RU:209.85.214.196 X-Spam-Status: No, score=-3.1 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,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: mail-pl1-f196.google.com Received: from mail-pl1-f196.google.com (HELO mail-pl1-f196.google.com) (209.85.214.196) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 03 Oct 2018 07:54:22 +0000 Received: by mail-pl1-f196.google.com with SMTP id q17-v6so3051287plr.8; Wed, 03 Oct 2018 00:54:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:in-reply-to:user-agent; bh=41XmzovnwXmDThPYMbN6LsfxbyadYEHuZ8TwS7fLuKc=; b=h45dTE7NnVAvf41ddoXir/WDCKax5bfzL8s1z1J81nCp4OkyKYHjnhCQbE/1eo2lhq NFANp7hS1vxNRQZ407lZhr2C/lSzHG+A9KEzF3P4aOx3uB85wKWgE0t4ldBqLYFXq9fZ aQY5qK51kesJUcjQM9MAxY5FBlaETbB70MXjUJOXha8NPRqy+qls2lag0FuaSxDwK5U7 ONRatKrADoHuScoCo17xKuVkUHg5bbKTY5ML+ucZpuhrnZvXLdW+gf0oJOAT7M06swN0 zsBE+Q8Avo/MOkwfSO+54qGglDhK0aK14NpM9pPx6u7FUxlFYbsWlEIr67hSeqoLpk8V xjRg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:in-reply-to:user-agent; bh=41XmzovnwXmDThPYMbN6LsfxbyadYEHuZ8TwS7fLuKc=; b=tScliAMSB6/qu2vzmv5L9iaMj/hIsTtQSRX+b6aQ2R60z+XyQgPjLYXZYSXTGtQdns O4QDRZt+6oRI7Lvwd+ZerF1qb4IonrF/uDsGoo+hO1rKGXeI5YShnIvFHn7TaQy9y71J FiFecRuQcTlkx3R5f/4H1FUOH7VcS0PIIkCd7jbIBqP8Se5/FqqaaDXjznW69QhRiVFq kBk6hNIOB4vlXsGzvqSskqr48M5sLtFvbWS0zUFqkb3CeBTujWrGY7WcZ0RCy3PlZwh4 qpJGRaqcwF50xxqrx4hHUTyJe3zqSC4m39AdJWhhPzOvW4NcxXXOzYBX3lO5HottryaF OL/g== X-Gm-Message-State: ABuFfogSAZz85HjXCaPE74mcEVD1plVs4ECwCnX7gXc354CQHYEfWnLV gthYKf30MkaRSBX+zfvMqNU= X-Google-Smtp-Source: ACcGV60Dhp0621ZHsSiEvTo98ilpJBjzQdhvRwiVKtgvJtprK+hq3vX9+bGV0FpVB7xuLcxbCdWWBw== X-Received: by 2002:a17:902:708a:: with SMTP id z10-v6mr317320plk.330.1538553261182; Wed, 03 Oct 2018 00:54:21 -0700 (PDT) Received: from bubble.grove.modra.org ([58.175.241.133]) by smtp.gmail.com with ESMTPSA id a2-v6sm877851pgc.68.2018.10.03.00.54.19 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Wed, 03 Oct 2018 00:54:20 -0700 (PDT) Received: by bubble.grove.modra.org (Postfix, from userid 1000) id 6BBAA805D0; Wed, 3 Oct 2018 17:24:16 +0930 (ACST) Date: Mon, 01 Jan 2018 00:00:00 -0000 From: Alan Modra To: Cary Coutant Cc: "H.J. Lu" , Michael Matz , Rich Felker , Carlos O'Donell , Florian Weimer , nsz@port70.net, Jan Beulich , Binutils , gnu-gabi@sourceware.org Subject: Re: RFC: Add GNU_PROPERTY_NEED_PHDRS Message-ID: <20181003075416.GD3179@bubble.grove.modra.org> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.9.4 (2018-02-28) X-IsSubscribed: yes X-SW-Source: 2018-q4/txt/msg00009.txt.bz2 On Tue, Oct 02, 2018 at 02:06:43PM -0700, Cary Coutant wrote: > 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. As Michael would say, it's a hack. ;-) > > 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 ; > } The script idea is probably not practical in view of all the variations of headers we'd need. PT_NOTE, PT_TLS, PT_GNU_EH_FRAME, PT_GNU_STACK, PT_GNU_RELRO come to mind, some of which depend on executable contents. I do agree that ld should be modified to create a PT_LOAD just for headers when needed, probably keyed off SIZEOF_HEADERS in a script. > 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. I don't particularly like the note section hack, but I can see why HJ did it that way. Adding a note section no doubt avoids objcopy bugs that would otherwise need to be fixed. -- Alan Modra Australia Development Lab, IBM