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 C646F387700B for ; Mon, 9 Mar 2020 02:36:33 +0000 (GMT) Received: by mail-ot1-x341.google.com with SMTP id a6so232731otb.10 for ; Sun, 08 Mar 2020 19:36:33 -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=SfVUlHSM66F12ZuzY4zm989aI8BqbFiXWC2iD1a9Z3Y=; b=DyBmoMQQVDdUlDcQpwqUSzvkwxJZX/QklyX57mLXtwmQiw/TVkhhVN/hqHTfQGwNsq aQHSrcrPAkIPpRD9QKpil8dV/9+e1BZ4PqcFp7tm0GdMFAkkeaDN18wQz2s393qBCIPe dlFMdQTXfESOobQQQp0vsKzrdeYoyfoa//masTYuxxj2ZUOwllXXyCG6DbbPECpZz0kQ 5sP1Il339WByW8/7/HPvcdbT7n9Z0CtnnI7Mu/yS+f7SFzINIrIQeTW98uB79hQc8zpT Y/aOHyhjZ5afZ4CrPQzjCnboy8BJMRivyEjV1QmNgn6DXG1qtG/mnQwWLhk80dxOf3Wd dblQ== 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=SfVUlHSM66F12ZuzY4zm989aI8BqbFiXWC2iD1a9Z3Y=; b=CGYlzYHlgoi0EXxcJhUhtt6rFqsrfT3ZuiqFtAJMjFXd0wn4XgH9pX/U8RXkmKf1Xf dJlDGnHtqLK4p3/Dk78uW0joVXUZN5qQYkcX/jkPY5j4M0/OCRL3iPVLgNZSHjXs1DWv E96gSgGTcP5nnVU9i1J2k7T01t/yeUhVDsRaC3lmSsYmziVzQ1K0saYuxPQJRCg2whPs WVKgSr3lmDY7sW5g7h0J7+YR8S7K1iC/XNJDTV1rHqkLCDtAG8TkM+Bt4UZChyueOLZM MxCyYrYNkNJslEzR+WwECuRlQh4UK3gJuzsm+8aPrLLJIRz+Szu2xXRmg14g8argRqat eRYg== X-Gm-Message-State: ANhLgQ052dzZK8sL/rWZVMK3N2FPSLq+Pakfa6OQTW1JDikMnymbyeoo vJI++kycuzE4fZL3ZSm/tNYseLH7bzSkJR9b5+M= X-Google-Smtp-Source: ADFU+vtYJtSjwhisJKuAK7puBOnpLS4l3Q0j90+I6HTjqQtOBpMQNF+70Kilike/ZZ+3NIi/oIhNiwiMipcNv47OcrA= X-Received: by 2002:a9d:19ef:: with SMTP id k102mr8399802otk.220.1583721393167; Sun, 08 Mar 2020 19:36:33 -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: <20200309022309.GK5384@bubble.grove.modra.org> From: "H.J. Lu" Date: Sun, 8 Mar 2020 19:35:56 -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 02:36:34 -0000 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. -- H.J.