From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: 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 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=redhat.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=redhat.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1694573006; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=d9RIpHIg+wLvGQjbJYJNIt7dBp7MTQaMATUS2XF7iv0=; b=ice8x8OIK+lQW5MLVy9wBfSNjLl3sybqeUQ2XO4b49fc7eNi3Lbx8NKPmgNDH5/lWdbxzJ gNviW1f37G5ZzlxQl7rc7FaEnielPglKzusbfT/I/swO7t4H/bMLu+ExA7oMe4vU/LTBHQ Yv1acE56YW8L/IkqDV33lp3vGikk/+c= 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 From: Kevin Buettner 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 List-Id: 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