From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 50377 invoked by alias); 27 Sep 2018 13:07:59 -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 50352 invoked by uid 89); 27 Sep 2018 13:07:59 -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:sk:87r2hfq, H*i:sk:87r2hfq 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-qt1-f176.google.com Received: from mail-qt1-f176.google.com (HELO mail-qt1-f176.google.com) (209.85.160.176) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 27 Sep 2018 13:07:57 +0000 Received: by mail-qt1-f176.google.com with SMTP id x23-v6so2626962qtr.1 for ; Thu, 27 Sep 2018 06:07:57 -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=ROKtoNtsuBCmAhTJGwgwDPaqFqrxdY2u5Qc7ULtwlMo=; b=bNtGK5Eusv9KsB6AOmB0FIm8WwSbZU5hlqPj5PtbxsuUyj9VkxME0jywXO9BzPMkqF wGCww+97TgJ2FJpDRtbPj9JjRDBCur8oh6k0ZILy4D+ccRqAvi5f7BSgPVhmlJAhbcs+ 26aix73mRQiq2ZIhahc4S/WSsPp9d9yv5QErepdbth8mv4uqJfOPiVsNU3J0HCNLyHT5 RvgXpFMFTwiL/GO5NrXa/ahJJY7XB9VLX86M3LarjA21ZEim+8koUe7wr9zvSSVQuj9W iUDISG7L7xmZnheeMwt5SIS7D1WcSk2pyRQsSWjfJdH57osk3O0RFe7yyz7e8hYJjbMR 4KlA== X-Gm-Message-State: ABuFfogYIDSUiATtQwmqEA/FEgT7PR/KTmpZv8N2L/lyTdgpKE8ouSXy skZv1dxZxfwKF4PlVq3FyUc7XKuFpG9hRQ== X-Google-Smtp-Source: ACcGV61iWADP0NpqtIEm5Kyb6KMDr0TdooSwUNf6Cy1byCljESFsTLBHCFpgEAMZZh6HHhi+ljXtQw== X-Received: by 2002:ac8:145:: with SMTP id f5-v6mr7828434qtg.221.1538053675747; Thu, 27 Sep 2018 06:07:55 -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 e29-v6sm1252407qte.47.2018.09.27.06.07.53 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 27 Sep 2018 06:07:54 -0700 (PDT) Subject: Re: RFC: Add SHT_GNU_PHDRS To: Florian Weimer , "H.J. Lu" Cc: 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> From: Carlos O'Donell Openpgp: preference=signencrypt Organization: Red Hat Message-ID: <73bd396c-43be-2922-fce4-17ee835d862e@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: <87r2hfqes1.fsf@oldenburg.str.redhat.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2018-q3/txt/msg00019.txt.bz2 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 > 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. -- Cheers, Carlos.