From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 112582 invoked by alias); 27 Sep 2018 12:54:50 -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 112557 invoked by uid 89); 27 Sep 2018 12:54:49 -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.9 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,SPF_PASS autolearn=ham version=3.3.2 spammy=Hx-languages-length:1093, H*i:sk:87va6rq, zero-sized, zerosized X-Spam-Status: No, score=-2.9 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-f172.google.com Received: from mail-oi1-f172.google.com (HELO mail-oi1-f172.google.com) (209.85.167.172) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 27 Sep 2018 12:54:47 +0000 Received: by mail-oi1-f172.google.com with SMTP id s69-v6so1999280oie.10; Thu, 27 Sep 2018 05:54:47 -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=5ZBNIJFlpf56LwuDNj8dTNB4SSmurEFXqkjvuW+sCuQ=; b=HihHLgftDngyY9pb+smOdkaX2ozakZV4669W7hLlNFzSu0y1iVqmTFRDqZ9ctg5rZD f/NdyfSrUr6usdAX23hAFg8OmIsp2Tuh5E2YmFujiw7NVhlxJD9oWRxR06cshkWljrUD Itj4uj+3TJothHOgA70gJ6xz/hXekWXFE5WNb9XEP7FGaUlc9WceQCmKsCwerXWqQQud vswAsVxc8Io7nfhwTY1UZdlzn0i4ZutgxhX+q8RLICcD6sViigaWfn0b0tL750EX//Ng 3c8ZAki92qoOEBA5oJnKAKDcyULnSYsZerY4OmFZbgv/5JyFENk8atS34dC4/sUGYqYq v8iQ== 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=5ZBNIJFlpf56LwuDNj8dTNB4SSmurEFXqkjvuW+sCuQ=; b=IYpAe5GATt7yWlpj6PkFVGusnhKQmEpNZqc8HsoD69mDKm9SPHrsE7sn4ruuXqvgvd +7vik+p22bS25ld0oP3twLhrcnLBnatK/n0BKYU1CY++kywtJh436ge5DFA8x5D5gKc7 jfcLqnCOsGMUnMrwxpHcPjhFjrdWnWLoc9dwm6Mjs1d9jLXhtdIlnR2cxOZDqi64XVRJ Ss9b82ZFA0gXzVCLCM95wrsYuETXz4g6jm1zgo+j91Y61htqMWE3XqWKXIfj4B1PRLEH MrGnEt0tB6+izZt5iu3lCS5peWXDtcZSPxrVDOkvNzQk7n/j/VeIpejnlKSJjXN5i45K xT6Q== X-Gm-Message-State: ABuFfoig/FxdFbHdUTc0VA0j4mtOHpiG2h3Fni/6w79ekfqoLs4t/L4g 4ZfWF5Wy+CCnSmo2WmaO2ysbxrJtCIhBFaNWs9Q1bTzm X-Google-Smtp-Source: ACcGV60eD6krLLvRcpc4eZouKdTqXYhgECRnI853gEE9PweZYyItKF8j95MhqDzApy7/kiYwhbPW6+vNW8hZEq89kCA= X-Received: by 2002:aca:5a45:: with SMTP id o66-v6mr3215425oib.155.1538052886114; Thu, 27 Sep 2018 05:54:46 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a4a:4d44:0:0:0:0:0 with HTTP; Thu, 27 Sep 2018 05:54:05 -0700 (PDT) In-Reply-To: <87va6rqfg6.fsf@oldenburg.str.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> From: "H.J. Lu" Date: Mon, 01 Jan 2018 00:00:00 -0000 Message-ID: Subject: Re: RFC: Add SHT_GNU_PHDRS To: Florian Weimer Cc: 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/msg00017.txt.bz2 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. -- H.J.