From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id wfsEBuchAWUERBUAWB0awg (envelope-from ) for ; Tue, 12 Sep 2023 22:43:51 -0400 Authentication-Results: simark.ca; dkim=pass (1024-bit key; secure) header.d=sourceware.org header.i=@sourceware.org header.a=rsa-sha256 header.s=default header.b=dkPwTGq7; dkim-atps=neutral Received: by simark.ca (Postfix, from userid 112) id 0A3F11E0C3; Tue, 12 Sep 2023 22:43:51 -0400 (EDT) Received: from server2.sourceware.org (server2.sourceware.org [8.43.85.97]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (prime256v1) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPS id EFE051E092 for ; Tue, 12 Sep 2023 22:43:48 -0400 (EDT) Received: from server2.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 33AC33858C31 for ; Wed, 13 Sep 2023 02:43:48 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 33AC33858C31 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1694573028; bh=d9RIpHIg+wLvGQjbJYJNIt7dBp7MTQaMATUS2XF7iv0=; h=Date:To:Cc:Subject:In-Reply-To:References:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: From:Reply-To:From; b=dkPwTGq7qpvIM6NJRuya9Dt9Mwg7g15FIiSaFSB42qMSCNtGJkQIroWt7TYqnHsG3 aJ2os7/AMsb7d8cishvfX+qJV1Q3uwYdIILL2/aFcmb2ntLgXqN2AtRuV1+9bc2cGX VW/jiusP3Veo3bIKz1tEfcSbco+u15jzgt3bp6a8= Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by sourceware.org (Postfix) with ESMTPS id 148A83858D3C for ; Wed, 13 Sep 2023 02:43:27 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 148A83858D3C Received: from mimecast-mx02.redhat.com (mx-ext.redhat.com [66.187.233.73]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id us-mta-624-YdbX7EmUO9uOqdw3WEbTvA-1; Tue, 12 Sep 2023 22:43:25 -0400 X-MC-Unique: YdbX7EmUO9uOqdw3WEbTvA-1 Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.rdu2.redhat.com [10.11.54.6]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mimecast-mx02.redhat.com (Postfix) with ESMTPS id 17435380670E; Wed, 13 Sep 2023 02:43:25 +0000 (UTC) Received: from f37-zws-nv (unknown [10.22.32.95]) by smtp.corp.redhat.com (Postfix) with ESMTPS id C75DF2156721; Wed, 13 Sep 2023 02:43:24 +0000 (UTC) Date: Tue, 12 Sep 2023 19:43:23 -0700 To: Tom Tromey Cc: gdb-patches@sourceware.org Subject: Re: [PATCH] Throw error when creating an overly large gdb-index file Message-ID: <20230912194323.7537de96@f37-zws-nv> In-Reply-To: <87o7i7jrxm.fsf@tromey.com> References: <20230909025521.3128935-2-kevinb@redhat.com> <87o7i7jrxm.fsf@tromey.com> Organization: Red Hat MIME-Version: 1.0 X-Scanned-By: MIMEDefang 3.1 on 10.11.54.6 X-Mimecast-Spam-Score: 0 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-4.8 required=5.0 tests=BAYES_00, DKIMWL_WL_HIGH, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, RCVD_IN_DNSWL_NONE, RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL, SPF_HELO_NONE, SPF_NONE, TXREP 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: gdb-patches@sourceware.org X-Mailman-Version: 2.1.30 Precedence: list List-Id: Gdb-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , From: Kevin Buettner via Gdb-patches Reply-To: Kevin Buettner Errors-To: gdb-patches-bounces+public-inbox=simark.ca@sourceware.org Sender: "Gdb-patches" On Tue, 12 Sep 2023 10:07:49 -0600 Tom Tromey wrote: > >>>>> "Kevin" == Kevin Buettner via Gdb-patches writes: > > Kevin> The header in a .gdb_index section uses 32-bit unsigned offsets to > Kevin> refer to other areas of the section. Thus, there is a size limit of > Kevin> 2^32-1 which is currently unaccounted for by GDB's code for outputting > Kevin> these sections. > ... > Kevin> This commit prevents the internal error from occurring by calling error() > Kevin> when the file size exceeds 2^32-1. > > I don't have a problem with this but... why is the section too long? > I wonder if this is covering up some other bug, like maybe not enough > symbol de-duplication. The problematic shared object is named libgraph_tool_inference.so and was created while building the python-graph-tool package on Fedora. The shared object is 3 GiB in size and the gdb-index section for it is 4.3 GiB in size. objdump -h shows that the largest section is .debug_str with a size of 0x81fe181e, which is a little over 2 GiB. The next largest is .debug_info with a size of 0x19691516 or about 406.6 MiB. Here is some of the objdump -h output: libgraph_tool_inference.so: file format elf64-x86-64 Sections: Idx Name Size VMA LMA File off Algn [...] 28 .debug_aranges 00004d70 0000000000000000 0000000000000000 083dd180 2**0 CONTENTS, READONLY, DEBUGGING, OCTETS 29 .debug_info 19691516 0000000000000000 0000000000000000 083e1ef0 2**0 CONTENTS, READONLY, DEBUGGING, OCTETS 30 .debug_abbrev 0012e28b 0000000000000000 0000000000000000 21a73406 2**0 CONTENTS, READONLY, DEBUGGING, OCTETS 31 .debug_line 03b842f5 0000000000000000 0000000000000000 21ba1691 2**0 CONTENTS, READONLY, DEBUGGING, OCTETS 32 .debug_str 81fe181e 0000000000000000 0000000000000000 25725986 2**0 CONTENTS, READONLY, DEBUGGING, OCTETS 33 .debug_line_str 0000656b 0000000000000000 0000000000000000 a77071a4 2**0 CONTENTS, READONLY, DEBUGGING, OCTETS 34 .debug_loclists 090b9227 0000000000000000 0000000000000000 a770d70f 2**0 CONTENTS, READONLY, DEBUGGING, OCTETS 35 .debug_rnglists 01e6cd27 0000000000000000 0000000000000000 b07c6936 2**0 CONTENTS, READONLY, DEBUGGING, OCTETS I extracted .debug_str using obj_copy, replaced the \0 characters with newlines, and then used sort and uniq on that output. There were no duplicate lines. Altogether, there are 1,212,620 strings in .debug_str. I can't say that I fully understand the layout of the constant pool, but it appears that all of the strings from .debug_str will end in the latter part of it. So, if I'm right, that alone accounts for nearly half the size of the index file. Kevin