From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 65921 invoked by alias); 27 Sep 2018 15:18:34 -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 65901 invoked by uid 89); 27 Sep 2018 15:18:34 -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,RCVD_IN_DNSWL_NONE autolearn=unavailable version=3.3.2 spammy=H*f:CAMe9rOrW38N, H*f:sk:2H-bVGr, H*i:CAMe9rOrW38N, H*i:sk:2H-bVGr X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_NONE autolearn=unavailable version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on sourceware.org X-Spam-Level: X-HELO: mail-qk1-f172.google.com Received: from mail-qk1-f172.google.com (HELO mail-qk1-f172.google.com) (209.85.222.172) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 27 Sep 2018 15:18:32 +0000 Received: by mail-qk1-f172.google.com with SMTP id g20-v6so690737qke.9 for ; Thu, 27 Sep 2018 08:18:32 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:cc:references:from:openpgp :organization:message-id:date:user-agent:mime-version:in-reply-to :content-language:content-transfer-encoding; bh=wv5DYWSyPrzVoCH552h/FzgmeWtSOJ3xh2qTG9Zbbcc=; b=jHXVc155qVPLBhgDIdvtm5xYpd0PGbkXN9Kr+CjWhIqqWnGaUBELBXdPJFnoV3qxfu hMCzCSDyR8QPa6ASsIguEy980UQ2n4jTS741mX+BXFOavaDxqfDtwfrTs587OB41pofr I3TWPiaocb408nH/GIKEZODO12zhNGN69uN2qUMYFkWRnAVGDmVzZZRqx1tsN7CybQC7 bd9Uq+e/gwRA612U0PFcthfcGuP0dWPISv/Jo6Wel6Bg/OrlQFS5BqqvGI3mGbcJD7xi 0nyUKLy7HxUgubEH2kr/loQdeNea0bRyQmws+lW+mf0oPJPqrU8i6sU7mseb6Z1nkyXd KF6g== X-Gm-Message-State: ABuFfojgM8mY3G8eaya8ifIlwiP1ShaBJLRKYiZw9e1mw53FKXePpyz3 hemFes7LQWD8XF690BzAe02pHf0s8Ne0PQ== X-Google-Smtp-Source: ACcGV62ODrSB9uoxlETOdMMPZJPd7hvKN7vO6dNtF1CwZuLWRrar22M6NdCj/6iPd9jtuN5ITa6pXg== X-Received: by 2002:a37:35c8:: with SMTP id c191-v6mr8492287qka.100.1538061507302; Thu, 27 Sep 2018 08:18:27 -0700 (PDT) Received: from [10.150.73.190] (247.sub-174-196-128.myvzw.com. [174.196.128.247]) by smtp.gmail.com with ESMTPSA id x14-v6sm1149578qkf.59.2018.09.27.08.18.25 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 27 Sep 2018 08:18:26 -0700 (PDT) Subject: Re: RFC: Add SHT_GNU_PHDRS To: "H.J. Lu" Cc: Florian Weimer , Szabolcs Nagy , Jan Beulich , Rich Felker , Binutils , gnu-gabi@sourceware.org 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: Carlos O'Donell Openpgp: preference=signencrypt Organization: Red Hat Message-ID: <0d529e75-beb2-3ba6-f4cc-e99d50880220@redhat.com> Date: Mon, 01 Jan 2018 00:00:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2018-q3/txt/msg00021.txt.bz2 On 9/27/18 9:20 AM, H.J. Lu wrote: > 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. Which other tools? Specific examples please. The main problem we have to solve is: * Segfault when trying to access program headers which are expected to be mapped in by the leading pages of the PT_LOAD segment. We can't solve *all* the problems. The correct solution to the above is to improve the semantics that the toolchain relies upon to map the phdrs. Some questions which we might get asked is: * How does a running program know it's *safe* to look at it's own phdrs? * How many downstream tools are impacted? Do they really need to understand SHT_GNU_PHDRS? >>> 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 :-). My apologies HJ, I did not intend this to sound like an attack on your original design, just that a new design like SHT_GNU_PHDRS could be created with reliable semantics. -- Cheers, Carlos.