From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-oi1-x243.google.com (mail-oi1-x243.google.com [IPv6:2607:f8b0:4864:20::243]) by server2.sourceware.org (Postfix) with ESMTPS id F09EA394843F for ; Mon, 9 Mar 2020 01:36:41 +0000 (GMT) Received: by mail-oi1-x243.google.com with SMTP id d62so8571445oia.11 for ; Sun, 08 Mar 2020 18:36:41 -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=iA1QcwlXcoAmWD3jftPbFU4PLsxfqdTcnM8BocfPJkA=; b=gsq+sMzGFuCYRCdqAggL4xp62k1kKIafdVNvod2ezm5Gze1RGlA+3pdFXkYCNtSYes hc679JqUlTYP34wpU+hV6P0f0vlsFZaLEm0Hq9VrPccE0mJHevcjkjzGMefKJQW1JlSN GJk+NNGCCpJrcNI18fdGNyfhxScUDl686Jud9hCjVS/6FQhIzB6GQsuUce2m6wQ77bxo FaPblVwfW0mA+CXaT+oCAcY0XnNfJddNjw0INBb+Lj8Erbr8KoDZywklz8inxF4qJZ9y ju9q7priIIpS8oBuO1OAyt3XKVSMav6pVDFVWsCuRu8lqV48CMVzO9xwhWxAs7uJJbvC 3zSw== 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=iA1QcwlXcoAmWD3jftPbFU4PLsxfqdTcnM8BocfPJkA=; b=CvLBmtcb+SdKlELFRaHiMYU7QxNb9OWbprHwlo6p2Xndd1Lxx43QwkR50azl/T1NeL 4HVKU+wvRKeeEtjyCw+FUpUvu86dwa64fdwxS9WpY5y3RoxbMPOjJy5V/8nW43HSJ5Lj kK4tG14dpVTrUzhIO5UZ398z1Lw9adsrUnBf7oJV4XwUWzLkL+mLPBsby6EGeuC0E+Dt fvlgTeC5JhCthZ7bM/u5zFyXqZbkkIsrNdIDtHeST2GJDswJoPNGij4ZXVhCwf7Nysws 1/yIsEir14SCMaSiciPn0whxSF5b3z+x/49zmQvyRH7dHP2qXSrTTavJ/Uk34VDgj0jm zPcw== X-Gm-Message-State: ANhLgQ2d3NeUjrS7jmSYRfdmjGNVIc+qSxZLLmpMOfKfl8S0cE+Q0cp6 z2x20XJkLQlYOjwL6dBsz0kUPHj7Yiib9mOLoYo= X-Google-Smtp-Source: ADFU+vvHMIfsz6tmcH0qs43335t4G9po6TjEGDJOOx87EQhMtI9RzS3RvSQOWhzqW3KWaAt6JIWBow7NA/JkntrOuew= X-Received: by 2002:aca:ea56:: with SMTP id i83mr27617oih.156.1583717801342; Sun, 08 Mar 2020 18:36:41 -0700 (PDT) MIME-Version: 1.0 References: <20200308175947.GA911529@gmail.com> <20200308233553.GG5384@bubble.grove.modra.org> <20200309000543.GJ5384@bubble.grove.modra.org> In-Reply-To: <20200309000543.GJ5384@bubble.grove.modra.org> From: "H.J. Lu" Date: Sun, 8 Mar 2020 18:36:05 -0700 Message-ID: Subject: Re: RFC: [PATCH] ELF: Don't require section header on ELF objects To: Alan Modra Cc: Binutils , Kaylee Blake Content-Type: text/plain; charset="UTF-8" X-Spam-Status: No, score=-7.1 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, GIT_PATCH_2, 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: Mon, 09 Mar 2020 01:36:42 -0000 On Sun, Mar 8, 2020 at 5:05 PM Alan Modra wrote: > > On Sun, Mar 08, 2020 at 04:46:51PM -0700, H.J. Lu wrote: > > On Sun, Mar 8, 2020 at 4:35 PM Alan Modra wrote: > > > > > > On Sun, Mar 08, 2020 at 11:06:33AM -0700, H.J. Lu wrote: > > > > On Sun, Mar 8, 2020 at 10:59 AM H.J. Lu wrote: > > > > > > > > > > Any comments? > > > > > > > > > > Kaylee, do you have copyright paper with FSF? > > > > > > > > > > H.J. > > > > > --- > > > > > Section header isn't mandatory on ELF executable nor shared library. > > > > > This patch adds a new linker option, -z nosectionheader, to omit ELF > > > > > section header when building an executable or shared library, adds > > > > > an objcopy and strip option, --remove-section-header, to remove ELF > > > > > section header from an executable or shared library. > > > > > > > > > > The PT_DYNAMIC segment contains DT_HASH/DT_GNU_HASH/DT_MIPS_XHASH, > > > > > DT_STRTAB, DT_SYMTAB, DT_STRSZ and DT_SYMENT, which can be used to > > > > > reconstruct dynamic symbol table when section header isn't available. > > > > > For DT_HASH, the number of dynamic symbol table entries equals the > > > > > number of chains. For DT_GNU_HASH/DT_MIPS_XHASH, only defined symbols > > > > > with non-STB_LOCAL indings are in hash table. Since in dynamic symbol > > > > > table, all symbols with STB_LOCAL binding are placed before symbols with > > > > > other bindings and all defined symbols are placed before undefined ones, > > > > > > > > It should read > > > > > > > > --- > > > > all symbols with STB_LOCAL binding are placed > > > > before symbols with other bindings and all undefined symbols are placed > > > > before defined ones, > > > > --- > > > > > > That's new to me. I don't think there is any ordering in .dynsym > > > among non-local symbols. > > > > I will get clarification from gABI group. > > Well we certainly don't do such sorting. For example, from a freshly > build ld/ld-new --enable-targets=all > > 148: 0000000000f08380 4 OBJECT GLOBAL DEFAULT 25 opterr@GLIBC_2.2.5 (3) > 149: 0000000000402f80 0 FUNC GLOBAL DEFAULT UND calloc@GLIBC_2.2.5 (3) > 150: 0000000000881536 35 FUNC GLOBAL DEFAULT 13 _obstack_allocated_p > I will make 2 changes: 1. Update -z nosectionheader to guarantee that the last entry in dynamic symbol table is defined. 2. Update --remove-section-header to issue an error if the last entry in dynamic symbol table is undefined. -- H.J.