From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ot1-x341.google.com (mail-ot1-x341.google.com [IPv6:2607:f8b0:4864:20::341]) by server2.sourceware.org (Postfix) with ESMTPS id A3C0A38A2416 for ; Mon, 9 Mar 2020 04:14:58 +0000 (GMT) Received: by mail-ot1-x341.google.com with SMTP id a6so376413otb.10 for ; Sun, 08 Mar 2020 21:14:58 -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=8xT5deKgi/qxbfS5AYOFngMAj6volztKsdjlrnMvGc4=; b=J5KOmsowlK3SuIxA80YnLgE0QaVc8Dz6vwGdT0va54GYsQcPU15B4fEvZI8M/A1nfE Modixksk5Bf699fP+X2QbLcGtqyJcpMZYrBF1DFz1hrNICPb1RtTDPvLLijeqq9RGYRK NxXameyCMu3/zX130kM1fN5BKfbiUTG95F5ARio/52A36JX62H6vzHmDEfz+QeTD/jkZ NLxZsq5wmGW/bjuMCSpP9BEfCNeiMo3b+GQAaP5pdAi58dskkFAcQahp3kwP8uUcYjaM o1ylOCXnJJWoGOAWvjN9ZzGcwLWMsvDDmi1D8PMemk3X1+EATGhmI6Jzsp3+rjL7DK9Q M2Qw== 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=8xT5deKgi/qxbfS5AYOFngMAj6volztKsdjlrnMvGc4=; b=ncyipU7o1Ytlr/GWJk8YCafYQU25lhWVunA9/Ac+qijGiRWGDgPXJkgdBKCqW9ZCjV CLY7ccmoD9bt4OW2ulaPW8tG1+/d7bFFIfGvDnLlWfXh8AS7hAJmT7F4nQDuV7dXVBOL TGwuHcv/KmfXmLRr0p36U4JOPzWvIG26njsLWpWU1ji5U3iykhwPXwFekraV2pmiOWS9 oYPCPv3djtm6uEvJ0yu9/lER9GdXfH4nAbZmQRTesPRR8rIt8tSRaWXyrijbV+Boece+ hoyh52KjqrZqV+iRfAtGV8ExIQbFTcqT2RFNnhtVsT+UtkZeyK0ooelSIFCD6PDA/LLW 5j/g== X-Gm-Message-State: ANhLgQ07tAGksj34kx5/dt8qRO8qz28KOnzKS+IHaWcvJ8MW0nLVhcw1 tQBDqLKJ2z0QkdUkO1nMlk7pUVyfanIcljsJWSM= X-Google-Smtp-Source: ADFU+vu1hYSDwtAK5mDP2iHFkQ33yL7JkRxxWfzq33tvxgul2ZcXosri0qyjsuX0/sJrqtFrWSP7uB29Ysn1abuPayw= X-Received: by 2002:a9d:21c5:: with SMTP id s63mr11163958otb.142.1583727297926; Sun, 08 Mar 2020 21:14:57 -0700 (PDT) MIME-Version: 1.0 References: <20200308175947.GA911529@gmail.com> <20200308233553.GG5384@bubble.grove.modra.org> <20200309000543.GJ5384@bubble.grove.modra.org> <0ad58560-3dd4-badd-5661-9f74905a7df3@gmail.com> <20200309022309.GK5384@bubble.grove.modra.org> In-Reply-To: From: "H.J. Lu" Date: Sun, 8 Mar 2020 21:14:21 -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: Mon, 09 Mar 2020 04:14:59 -0000 On Sun, Mar 8, 2020 at 7:35 PM H.J. Lu wrote: > > On Sun, Mar 8, 2020 at 7:23 PM Alan Modra wrote: > > > > On Mon, Mar 09, 2020 at 12:29:48PM +1030, Kaylee Blake wrote: > > > On 9/3/20 12:06 pm, H.J. Lu wrote: > > > > On Sun, Mar 8, 2020 at 5:05 PM Alan Modra wrote: > > > >> 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. > > > > > > > > > > With some testing, it seems like ld will emit an ordered symbol table > > > iff it's using the DT_GNU_HASH hash table style > > > > It doesn't. The snippet of .dynsym I posted was from a binary with > > DT_GNU_HASH. elflink.c:_bfd_elf_link_renumber_dynsyms should convince > > you that any ordering seen is by chance. > > > > >, and my understanding is > > > that DT_GNU_HASH in fact requires this behaviour. > > > > Apparently not. ;-) > > > > > So in that case, we > > > don't need to do an additional check, because we only need the ordering > > > if we are looking up through DT_GNU_HASH instead of DT_HASH. > > > > > > -- > > > Kaylee Blake > > > C is the worst language, except for all the others. > > > > x86 backend does: > > if (!local_undefweak > && !h->def_regular > && (h->plt.offset != (bfd_vma) -1 > || eh->plt_got.offset != (bfd_vma) -1)) > { > /* Mark the symbol as undefined, rather than as defined in > the .plt section. Leave the value if there were any > relocations where pointer equality matters (this is a clue > for the dynamic linker, to make function pointer > comparisons work between an application and shared > library), otherwise set it to zero. If a function is only > called from a binary, there is no need to slow down > shared libraries because of that. */ > sym->st_shndx = SHN_UNDEF; > if (!h->pointer_equality_needed) > sym->st_value = 0; > } > > Entries in DT_GNU_HASH were originally defined. A backend > may change some entries to undefined. I think my patch is OK. > [hjl@gnu-cfl-2 pr25617]$ cat y.s .data bar: .dc.a foo [hjl@gnu-cfl-2 pr25617]$ gcc -c y.s [hjl@gnu-cfl-2 pr25617]$ ./ld -shared y.o --hash-style=sysv [hjl@gnu-cfl-2 pr25617]$ readelf -D -s a.out Symbol table for image: Num Buc: Value Size Type Bind Vis Ndx Name 1 0: 0000000000000000 0 NOTYPE GLOBAL DEFAULT UND foo [hjl@gnu-cfl-2 pr25617]$ ./ld -shared y.o --hash-style=gnu [hjl@gnu-cfl-2 pr25617]$ readelf -D -s a.out [hjl@gnu-cfl-2 pr25617]$ I will update my patch to not to generate such binary without section header. -- H.J.