From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 113125 invoked by alias); 27 Sep 2018 12:38:12 -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 113104 invoked by uid 89); 27 Sep 2018 12:38:11 -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=Hx-languages-length:1799 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-f45.google.com Received: from mail-ot1-f45.google.com (HELO mail-ot1-f45.google.com) (209.85.210.45) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 27 Sep 2018 12:38:10 +0000 Received: by mail-ot1-f45.google.com with SMTP id i12-v6so2408118otl.1; Thu, 27 Sep 2018 05:38:09 -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=lBFk5duyTTz+DiyHSBIpeLpPiX0visiOj488eQMrfWs=; b=hkdfbf5b4K/yjmjE5LW7VumSkWhvGSGM9NKZjfOpgabb7owj+5xqQtSGWzXIoyuL+h 1Pa79xRyy+tOYgeOSimfIdh1YgCYfhGdnJv2v3b7VluY6LR+z1yU2lUiYB2HkNnediZ1 Cjei1eRHSAAssqzq8jNqM6r9dW0hq9BDPizddBRICBXNaQo05dt90e4w8bDjAvH5LEcv aVYh62LsUUBJBCQRU6C0Vu5rxC6ytX5+V4y7iP5TIszFSGuV6+lMW2LSCDoQwQiNdsok DaZvveFevf0P069ozOdL+rT/lsMTB5dShDeFJGomBmpGsrBVyoIRQ9CD84/Og6SDOseE 8n3g== 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=lBFk5duyTTz+DiyHSBIpeLpPiX0visiOj488eQMrfWs=; b=lvzNnYo2Ug3FHvImzqN7vIJcXZ81sRBebbLWl/8skG+W92EiS4tQphGxWxgoUQ20Am 1m81We929SUAKbDnpZLg6ha6D3UNrsvUNI1MpBGoZUwyEfLpzCGoqbygc64jPbIvo4D3 WQcwmn7hjpMUuNOMDiOIP1+slm+rZCxzBiWxI7fcZmWMbwf8GWbTWk/K9LPIpPArpPoR KGMFCoHQu+6dGpP1HqZRSOa22WCIbAbiQ1txXIO7EFJgkUz1nrLPaqUAbfR46WnEh0pi FPxNmJ6xj1mIOt1a+7Y/WGXxBOJSmvXwinX/9MpwbaFCnu7iUN2ugvfRSW5/VRv2aT78 PPoQ== X-Gm-Message-State: ABuFfoh7qZCImRXi4pFnk8TPDPuONi8nwyg0iWNlWO5Y4PnoRRhBNkmX mLl0zO9D+CeQkHygvigKbKMmHC65P43uXqNQkkY= X-Google-Smtp-Source: ACcGV610j2jqtpiWmSoSWHoByV3NPLKgMn0WR7Hjii74xck/2wGg6CfTmNEg+t4HZrgC4qltRJntVECterCKO9ULiLc= X-Received: by 2002:a9d:4d01:: with SMTP id n1-v6mr151139otf.121.1538051888233; Thu, 27 Sep 2018 05:38:08 -0700 (PDT) MIME-Version: 1.0 Received: by 2002:a4a:4d44:0:0:0:0:0 with HTTP; Thu, 27 Sep 2018 05:37:27 -0700 (PDT) In-Reply-To: <20180927103539.GJ10209@port70.net> References: <87tvmbv8hp.fsf@oldenburg.str.redhat.com> <5BAC7D6802000078001EC6D1@prv1-mh.provo.novell.com> <87pnwzuz8r.fsf@oldenburg.str.redhat.com> <20180927103539.GJ10209@port70.net> From: "H.J. Lu" Date: Mon, 01 Jan 2018 00:00:00 -0000 Message-ID: Subject: Re: RFC: Add SHT_GNU_PHDRS To: Szabolcs Nagy Cc: Florian Weimer , 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/msg00015.txt.bz2 On Thu, Sep 27, 2018 at 3:35 AM, Szabolcs Nagy wrote: > * Florian Weimer [2018-09-27 10:21:40 +0200]: >> * Jan Beulich: >> >>>> On 27.09.18 at 07:01, wrote: >> >> * H. J. Lu: >> >> >> >>> I am proposing >> >>> >> >>> #define SHT_GNU_PHDRS 0x6ffffff4 /* Dummy section for program header */ >> >>> >> >>> This is a special read-only SHF_ALLOC zero-size data section. It is the >> >>> first output section, which will force a data PT_LOAD segment with program >> >>> header before the code-only PT_LOAD segment, >> >> >> >> Is it actually a requirement in the ELF specification that all bits >> >> loaded via segments are covered by sections as well? >> > >> > Hardly, because the presence of a section table isn't required >> > in the first place in an executable (iirc). >> >> I think so too, and that is why I don't understand this section hack is >> needed. > > if there is no read-only alloc section then the program > headers are currently not part of a load segment. > https://sourceware.org/bugzilla/show_bug.cgi?id=23428 > > 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. -- H.J.