From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from gnu.wildebeest.org (gnu.wildebeest.org [45.83.234.184]) by sourceware.org (Postfix) with ESMTPS id F1D1B385803E for ; Tue, 9 Aug 2022 10:30:24 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org F1D1B385803E Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=klomp.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=klomp.org Received: by gnu.wildebeest.org (Postfix, from userid 1000) id 01172301FEBD; Tue, 9 Aug 2022 12:30:23 +0200 (CEST) Date: Tue, 9 Aug 2022 12:30:23 +0200 From: Mark Wielaard To: generic-abi@googlegroups.com Cc: elfutils-devel@sourceware.org, Di Chen , Milian Wolff Subject: Re: Making DT_HASH optional? Message-ID: <20220809103023.GC553@gnu.wildebeest.org> References: <7864fc03-cd24-2754-a390-a70627af9574@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) X-Spam-Status: No, score=-5.4 required=5.0 tests=BAYES_00, JMQ_SPF_NEUTRAL, KAM_DMARC_STATUS, SPF_HELO_NONE, SPF_PASS, TXREP, T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org X-BeenThere: elfutils-devel@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Elfutils-devel mailing list List-Unsubscribe: , List-Archive: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 09 Aug 2022 10:30:26 -0000 Hi, CCing the elfutils-devel list where this issue (of missing DT_SYMTAB_COUNT or DT_SYMTABSZ) does come up occasionally. Which are needed if you only have the dynamic segment, and not the section headers, to enumerate all symbols. On Mon, Aug 08, 2022 at 05:29:19PM -0700, Cary Coutant wrote: > > We recently had a case where dropping DT_HASH from the generic > > glibc binaries broke an ELF consumer. > > > > For the "real world" details see: > > https://sourceware.org/pipermail/libc-alpha/2022-August/141302.html > > > > I was surprised to see that DT_HASH was "mandatory" in the existing > > published standard. > > > > Why is it mandatory and not optional? > > > > Should we and could we make it optional? > > This is an odd situation. > > DT_HASH is mandatory because the "nchain" field in the hash table is > the only way to know the number of symbols in DT_SYMTAB (unless you > still have a section table and look for the .dynsym section, which is > not something we want to require). But when the psABI has effectively > replaced DT_HASH with something newer, it makes sense for that > requirement to transfer to the newer table. I suppose the gABI could > say something like "mandatory unless the psABI provides for a > replacement in some form," but that doesn't feel right to me. In this > case, I think it's simply up to the psABI to override the gABI and say > that DT_HASH is optional if DT_GNU_HASH is present. Unfortunately, > that means that generic tools that know nothing of ELFOSABI_GNU or > ELFOSABI_LINUX would be unable to process DT_SYMTAB if they can't find > DT_HASH. > > I'd probably have preferred to have a mandatory DT_SYMTAB_COUNT or > DT_SYMTABSZ entry in the dynamic table, which would have enabled us to > make the hash table (in any form) optional. But the DT_HASH > requirement has been with us since the beginning of time. Do you know the reason for not having a DT_SYMTAB_COUNT or DT_SYMTABSZ? It is not intuitive that one can find the number of entries through the hash table. I don't think DT_GNU_HASH can simply be made optional and replace DT_HASH without adding something like DT_SYMTAB_COUNT or DT_SYMTABSZ because the gnu hashtable doesn't come with a simple symbol count. To find the symbol count you have to go through the whole gnu hash table to count the number of entries (which is a non-trivial amount of work). Cheers, Mark