From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mout-p-201.mailbox.org (mout-p-201.mailbox.org [80.241.56.171]) by sourceware.org (Postfix) with ESMTPS id 7D2B4395A455 for ; Fri, 13 May 2022 19:17:36 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 7D2B4395A455 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=43t.de Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=43t.de Received: from smtp2.mailbox.org (smtp2.mailbox.org [10.196.197.2]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange ECDHE (P-384) server-signature RSA-PSS (4096 bits) server-digest SHA256) (No client certificate requested) by mout-p-201.mailbox.org (Postfix) with ESMTPS id 4L0JLj1PTWz9sbG for ; Fri, 13 May 2022 21:17:33 +0200 (CEST) Message-ID: <716eb868d262e063382c7b63901fb02dfad9f2bb.camel@mailbox.org> Subject: bfd enforces a specific value of sh_info on SHT_GNU_verneed From: Thomas =?ISO-8859-1?Q?R=F6thenbacher?= To: binutils@sourceware.org Date: Fri, 13 May 2022 21:17:32 +0200 Content-Type: text/plain; charset="UTF-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-2.4 required=5.0 tests=BAYES_00, KAM_DMARC_STATUS, RCVD_IN_DNSWL_LOW, SPF_HELO_NONE, SPF_PASS, TXREP, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) 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: Fri, 13 May 2022 19:17:38 -0000 Hello, as stated in the subect, bfd (and therefore `objdump -d`) seems to fail in _bfd_elf_slurp_version_tables if the value of sh_info for a ".gnu.version_r" section (SHT_GNU_verdef) is zero. I couldn't however find a specification to justify this behaviour or anything specifying the sh_info field of this section type at all. The only reference I could find, was in the SUN "Linker and Libraries Guide", where they defined the sh_info value for their section type SHT_SUNW_verdef. But does this standard apply here? I'm asking, because a program I work with generates binaries that violate this constraint, but can't really justify why it should NOT just have a sh_info of zero in this section. Thanks in advance for your replies, Thomas