From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 51472 invoked by alias); 27 Sep 2018 13:21:09 -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 50984 invoked by uid 89); 27 Sep 2018 13:21:08 -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.7 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,SPF_PASS autolearn=ham version=3.3.2 spammy=H*i:sk:73bd396, H*f:sk:73bd396, our X-Spam-Status: No, score=-2.7 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,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-oi1-f175.google.com Received: from mail-oi1-f175.google.com (HELO mail-oi1-f175.google.com) (209.85.167.175) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 27 Sep 2018 13:21:06 +0000 Received: by mail-oi1-f175.google.com with SMTP id d63-v6so2070095oic.12; Thu, 27 Sep 2018 06:21:06 -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=4EJMMCWg298g8vYB5LtkSes0PeeGNUacJEX+kjZSdwE=; b=la1YT/WalS1lrvJQZsUIWUaRBwLgvTVOJOXjDixf6G2f1FHH6TOGnPFcMMZ7BWehVP B9XRfVf9ZGyZEgj2afTEGATteiTgqrgYkKhaJtwq/rLj0KA1TLJLkq1v7jMx0W9dbG9V eJvS0HtB9o5TbNA6TQAOTzOYceK99+VdsTUPj40b7PTfd7wljk9DLYBdeorL+q7MiDVi bX4W9S9KcaAK2g+Km5q5WarRXnqueEHTL10+4MkLSCI2QrrmegOLXv0OM0rFEba6LjIi fDYBRSTHUFG8fsnCFkUtewnrWwNjbaWfIoO6i942txJNQCYn+9mgrmd8Synx6gYgfNF9 /kkw== 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=4EJMMCWg298g8vYB5LtkSes0PeeGNUacJEX+kjZSdwE=; b=jUE5k8ujhYPLbGkoOk+an7OKzyNm8rX18czUqNCh2b+y5Xww84Nsf/uFqNcNNfrnjB GgVFEz3ereOdcXPLI69TtCgF1SU0FYCpGUn34SdU/M2EDrfGCmTeX/OuNWjR+jvhHfIu SDuQ3j2rFKTQlx3YA9geA/d7RnFwci0vKgl/gi8TuVHdjU3n7dGS2uuJKYDTFhpvpdD3 IPprhcb7gOnH2CHJSgDBcAaL6qtdDeiGg1QyxELzpRGlf7oK2HkM8eE7nBVek/axgVvj pqb0j1Huzk6GfFPImEujnFL77rAgSmu3L2MZY0hcGgtfZklg6yazP4nhLzNdy8dhALAe QqUA== X-Gm-Message-State: ABuFfogd7zaqwqA/6S1tc4r6VdqF5ejGzTTbtzMvP0s36Qq90S9sKnIA o8coAnfLKmI7Mv2JGTAgi6zbepfzJUl3D4ONn08= X-Google-Smtp-Source: ACcGV60xP5paGWctz9e7bQVqbAmYeGb/iTLkPyg1c4HwV/9rtICCKEaSxfVITJd7PAWKqwyNTpAc9DpEc+fjHIjmZ0Q= X-Received: by 2002:aca:f18a:: with SMTP id p132-v6mr3336145oih.14.1538054465123; Thu, 27 Sep 2018 06:21:05 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a4a:4d44:0:0:0:0:0 with HTTP; Thu, 27 Sep 2018 06:20:24 -0700 (PDT) In-Reply-To: <73bd396c-43be-2922-fce4-17ee835d862e@redhat.com> 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: "Carlos O'Donell" Cc: 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/msg00020.txt.bz2 On Thu, Sep 27, 2018 at 6:07 AM, Carlos O'Donell wrote: > On 9/27/18 8:57 AM, Florian Weimer wrote: >> * H. J. Lu: >> >>> On Thu, Sep 27, 2018 at 5:42 AM, Florian Weimer wrote: >>>> * H. J. Lu: >>>> >>>>> On Thu, Sep 27, 2018 at 3:35 AM, Szabolcs Nagy wrote: >>>>>> an alloc .phdr section covering the program headers solves >>>>>> this problem. if sections are not required for segments >>>>>> then simply the linker should ensure that there is always >>>>>> a load segment covering the program headers, possibly >>>>>> without containing any sections, however elf says >>>>>> "An object file segment contains one or more sections". >>>>>> >>>>>> i don't understand why a zero-size section is enough, what >>>>>> if phdr > pagesize? will that get covered by the load >>>>>> segment that is created for the zero-size section? >>>>> >>>>> Linker must keep this zero-size section in output and >>>>> create a PT_LOAD segment to cover it even if it is >>>>> the only SHF_ALLOC section in the PT_LOAD segment. >>>> >>>> Based on Szabolcs' comment, I don't think the section can be zero-sized. >>>> >>> >>> Why can't we put a zero-size section in a PT_LOAD segment? >>> Of course, we need to change linker to do it. >> >> 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 It depends on how we define it. I did experiment SHT_GNU_PHDRS to cover the whole program header. But other tools don't expect a section covering the program header. >> 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. > My current dummy program property note section sounds much better now :-). -- H.J.