From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20872 invoked by alias); 28 Sep 2018 13:43:36 -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 20844 invoked by uid 89); 28 Sep 2018 13:43:35 -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=-2.5 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.2 spammy=H*i:sk:CAJimCs, H*f:sk:CAJimCs, Hx-languages-length:1432, our X-Spam-Status: No, score=-2.5 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-ot1-f65.google.com Received: from mail-ot1-f65.google.com (HELO mail-ot1-f65.google.com) (209.85.210.65) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 28 Sep 2018 13:43:34 +0000 Received: by mail-ot1-f65.google.com with SMTP id j9-v6so6097853otl.2; Fri, 28 Sep 2018 06:43:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=Xqnelk6XUsaD6BreYeRFENDZ9o3EymGisdIMEukr1y4=; b=qHqHYBcmvqxroJf8MMU5XqDTvsuolg9HgChgh8W/Xier+zgt0v3Tq6h6dOENfzTrmf CawTqXV7A8ihtib4Ic6OCI4JmjVgD5rKThK4FrUfSi6/a2IPZrRcmmASYty2Swpoa6bX jm8hxAE0tF2aHzHOOcJOZKf+6S2CkpFE5D5whoeEahdsIvXDTGEa1HFjDhtaSfGFCHPR HjLlauebS/1D812+dUNfqGgwky5yem+hq0kAYfi05fl+HKVpJ+yiPb5eKevDsueWBqHO Ow5iL30auUQYbU95wHXDaA1FkYjtyOLvXzHBTtHRCrST5/Jqv8ULadxpK4hseHTvLLdE ooAA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=Xqnelk6XUsaD6BreYeRFENDZ9o3EymGisdIMEukr1y4=; b=OWYOiK9/UwA3n418SuVkrWcC6yU/5XPPVtwALNgj5SIipkWLnUN6QDTTegPeFA7R+w N5xWM0/PV71lXDFAa3eoywx8KK7JPqq56Ze03OWQF4fx2PUvFvXm8zAT0bpTuuH6QBFn zV5Fzq5xKu6YnK/9eslrt93p6DhyVPTy8CPJWYR9rIiYHdyB9TIGsprVBQEIGxvBVpSf hUQXJs+SKG5DfxUjEvfbmp3Fpc3/exibwpsAN2/BXNzL7nHeRONdbpVe109puBMfT5eW dmiEkfF4YBaZ9G+mRDo7aitkX9B+DlkCQHBCHkFTiVzqdbXsPWn+lzfTc9q3IZpNM4bl Phbw== X-Gm-Message-State: ABuFfoglp072tJBlzTKLp+TJ9zXl3A77fY67BL8uYOUsLTTvn+8XUccl 2Ip/TrbL6w3WdkmZvs2YKbxlq/F1sygxtrx7a2g= X-Google-Smtp-Source: ACcGV63CtOhh8mhpNwCcInWFaMpx3y//rSZY8/blV/qi9GkaYLhy9DXk2GCzICsV31hefAMQSK+6/tUOzJ74Z4kNOG8= X-Received: by 2002:a9d:753:: with SMTP id 77-v6mr9326878ote.344.1538142212583; Fri, 28 Sep 2018 06:43:32 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a4a:4d44:0:0:0:0:0 with HTTP; Fri, 28 Sep 2018 06:42:52 -0700 (PDT) In-Reply-To: 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> <73bd396c-43be-2922-fce4-17ee835d862e@redhat.com> From: "H.J. Lu" Date: Mon, 01 Jan 2018 00:00:00 -0000 Message-ID: Subject: Re: RFC: Add SHT_GNU_PHDRS To: Cary Coutant Cc: "Carlos O'Donell" , Florian Weimer , Szabolcs Nagy , Jan Beulich , Rich Felker , Binutils , gnu-gabi@sourceware.org Content-Type: text/plain; charset="UTF-8" X-IsSubscribed: yes X-SW-Source: 2018-q3/txt/msg00029.txt.bz2 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. 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. -- H.J.