From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-lf1-x144.google.com (mail-lf1-x144.google.com [IPv6:2a00:1450:4864:20::144]) by sourceware.org (Postfix) with ESMTPS id ED2D6395340C for ; Tue, 10 Mar 2020 00:14:55 +0000 (GMT) Received: by mail-lf1-x144.google.com with SMTP id q9so2671406lfc.10 for ; Mon, 09 Mar 2020 17:14:55 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=WN0e/1hV11Jye9Ag+c9Oer8OoAj0KpaAsMi2gDbbq2k=; b=J9p6bx7N64+wtuX5ETIzz/dihjeRVPy5LzR25tEQ5XsXc/swhr+ciMP7nMNCerOGEi dDtPZjJ4+OKvGUj5wOQRTGdqdrdQMuCTM8O4+par88zzSnt5bh6L0I8KTzU5wbF+wqfc TnSKO5mG7F795SLYnmA/nLOPrxqVm3Z9YsQJVqxr1po/ELHUGiWYhtG4LHBLmHGMECFl a4vGQHljFRoaf5U8qzHTqgSBATiJ0iLO90Ys5J6wFTG3qBx6ululiWCzLSjYiSjYwO4X itkbisx5oGwmxm6otBE5dqAFdLxCw7B4iPNTI7SkO9ve8pA0fVAHPJY4ThGUAI5WvNi+ cFOQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=WN0e/1hV11Jye9Ag+c9Oer8OoAj0KpaAsMi2gDbbq2k=; b=eksWEQQRCU0KEDKH9d/SnjYhY+WVdLYzTROz4N63W5GBXy9NB5LAq5Vra8LH78eld+ a0+SFoFcyvaWlWdZb65kLobW73tnEp1FUmYSuFh42OcqPjXdXO7E5ChroI7o+mHH8FUL PsQUNFYtQoSeUU3IJshqm+kGJpKhk3FN6GjC8DD+2D0evgf6d/3Z51QnLLsTpReiPBA7 IJmPgC3pM1orz8VNBOGEvGIjJpwAOHaz6KoFu+BwxH+rvx2i+gL0Di460D7sLhQkDRco 36HgAZ51tSIot4suwGZAolaOCUlo+PManmYjcKrpVDRO0k4z5a9Rtz7qT5CJYUiaLDhc PyCQ== X-Gm-Message-State: ANhLgQ3nW6ZEOA2e/Nrg+GSJfBRnkY1y4v/vNpIbyqpm2lK6ytmJCH88 29oqgV63CO9Kbd1Phd+igZxmkYTjIquDPsmJwqPZ4ezR X-Google-Smtp-Source: ADFU+vsGCuuNZg0ogf4gCfqecx7E7NpsHUEYJTfWLsEN7jVHqDWaQt8QBs38UCqWMxSSn77NHxMSWiLtbxrlKExM51E= X-Received: by 2002:a19:a415:: with SMTP id q21mr8509691lfc.21.1583799294723; Mon, 09 Mar 2020 17:14:54 -0700 (PDT) MIME-Version: 1.0 References: <20200308175947.GA911529@gmail.com> <87y2sac5er.fsf@mid.deneb.enyo.de> <79bc289f-9202-9aff-61c3-92c7190d2f7d@gmail.com> <20200309134427.GO5384@bubble.grove.modra.org> <871cf36a-5690-a8a7-68af-2cf0f54c5b5d@gmail.com> <20200309223449.GQ5384@bubble.grove.modra.org> In-Reply-To: <20200309223449.GQ5384@bubble.grove.modra.org> From: "H.J. Lu" Date: Mon, 9 Mar 2020 17:14:18 -0700 Message-ID: Subject: Re: RFC: [PATCH] ELF: Don't require section header on ELF objects To: Alan Modra Cc: Kaylee Blake , Binutils Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-2.1 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS autolearn=ham autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: binutils@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Binutils mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 10 Mar 2020 00:14:57 -0000 On Mon, Mar 9, 2020 at 3:43 PM Alan Modra wrote: > > On Tue, Mar 10, 2020 at 12:24:51AM +1030, Kaylee Blake wrote: > > On 10/3/20 12:14 am, Alan Modra wrote: > > > On Mon, Mar 09, 2020 at 11:24:44PM +1030, Kaylee Blake wrote: > > >> On 9/3/20 6:43 pm, Florian Weimer wrote: > > >>> In my opinion, it should NOT be possible to link against objects > > >>> without section headers. Lack of section headers clearly marks the > > >>> object as a run-time only object. This is useful if you want to > > >>> prevent developers to create DT_NEEDED dependencies on internal > > >>> libraries, for example. > > > > > > I agree. > > > > > >> For shared objects without debug symbols, the section header table is > > >> ~2kB on average of redundant data. I'm also not a fan of the > > >> inconsistency of having shared libraries that the dynamic linker is > > >> perfectly happy to load, but ld can't link against, especially since > > >> this seems like an oversight rather than an intended design decision. > > > > > > The ELF spec designed things that way. See figure 4.1 which I'll try > > > to represent in text. > > > > > > Figure 4-1: Object File Format > > > > > > |----------------------| |----------------------| > > > | ELF Header | | ELF Header | > > > |----------------------| |----------------------| > > > | Program header table | | Program header table | > > > | optional | | required | > > > |----------------------| |----------------------| > > > | Section 1 | | Segment 1 | > > > |----------------------| |----------------------| > > > | ... | | Segment 2 | > > > |----------------------| |----------------------| > > > | Section n | | Segment 3 | > > > |----------------------| |----------------------| > > > | ... | | ... | > > > |----------------------| |----------------------| > > > | Section header table | | Section header table | > > > | required | | optional | > > > |----------------------| |----------------------| > > > Linking View Execution View > > > > > > > I had interpreted that table in combination to various other references > > to which things are required vs optional in shared objects as meaning > > that the "execution view" applied to executables and shared objects, and > > the "linking view" applied to relocatable objects. You're saying that > > that table should be interpreted as saying that if a shared object is to > > be linkable, the spec is requiring it to have both sets of headers? > > Yes. Just below the table: "Files used during linking must have a > section header table". > I posted a new set of patches without linker support for PT_DYNAMIC: https://sourceware.org/pipermail/binutils/2020-March/110157.html -- H.J.