From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id BE7EF385DC0B; Tue, 12 Sep 2023 16:25:58 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org BE7EF385DC0B DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1694535958; bh=V2GDNMI1te0RQUZt752j1vefBuYfFE35ahaXdSFErpY=; h=From:To:Subject:Date:In-Reply-To:References:From; b=J/0uE+oCEVVozRsLzydR65VLODXuFaWEv5ATQYnYXkV14hAOM7JhpOsHn9x9RJl4E ig7gJTvF3e8mS7utUfy5kbXweuOGMhRG4yhdVu1kwPiSO0R3ZuuQzDNX7YIE02RrKb pRyUisFpPp7RT/rtayXhPtCpMnoWOicf9mNpHmgc= From: "vries at gcc dot gnu.org" To: gdb-prs@sourceware.org Subject: [Bug symtab/30841] [gdb, symtab] support .gnu_debugaltlink in gdb-add-index Date: Tue, 12 Sep 2023 16:25:58 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gdb X-Bugzilla-Component: symtab X-Bugzilla-Version: HEAD X-Bugzilla-Keywords: X-Bugzilla-Severity: enhancement X-Bugzilla-Who: vries at gcc dot gnu.org X-Bugzilla-Status: NEW X-Bugzilla-Resolution: X-Bugzilla-Priority: P2 X-Bugzilla-Assigned-To: unassigned at sourceware dot org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://sourceware.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 List-Id: https://sourceware.org/bugzilla/show_bug.cgi?id=3D30841 --- Comment #2 from Tom de Vries --- (In reply to Tom Tromey from comment #1) > My recollection is that in 'dwz -m' mode, all symbols from > PUs should be attributed to one of their containing CUs, Yes. That doesn't cover the case of a CU in the dwz file though. > and that the separate file should not require an index. That was added in this commit: ... commit c4973306879b6079bdfc997474a2cbbd89f49bd2 Author: Simon Marchi Date: Sun Jun 16 10:13:56 2019 -0400 Write index for dwz -m file PR 24445 ("dwz multifile index not written to index cache") exposed the fact that we are not doing things right when we generate an index for an object file that has is linked to a dwz file. The same happens whether the index is generated with the intent of populating the index cache or using the save gdb-index command. The problem can be observed when running these tests with the cc-with-dwz-m board: FAIL: gdb.base/index-cache.exp: test_cache_enabled_hit: check index-cache stats FAIL: gdb.dwarf2/gdb-index.exp: index used FAIL: gdb.dwarf2/gdb-index.exp: index used after symbol reloading When generating the index for such file and inspecting the CU list of t= he resulting index (with readelf --debug-dump=3Dgdb_index), we can see som= ething like: CU table: [ 0] 0x0 - 0xb9 [ 1] 0x0 - 0x44 This is supposed to be a sorted list of the ranges of all CUs in the file this index represents, so already having some overlap is a red flag. It turns out that we save the ranges of CUs coming from both the main file and the dwz file in the same index. After digging a little bit, it became quite obvious that the index in the main file should only list the CUs present in the main file, and a separate index should be generated for the dwz file, listing the CUs present in that file. First, that's what happens if you run dwz on a file that already has a GDB index embedded. Second, dwarf2read.c has code to read an index from a dwz file. The index in the dwz file is actually required to be present, if the main file has an index. So this patch changes write_psymtabs_to_index to generate an index for the dwz file, if present. That index only contains a CU list, just like what the dwz tool does when processing a file that already contains an index. Some notes about the implementation: - The file management (creating a temp file, make sure it's close/removed on error - in the right order) is a bit heavy in write_psymtabs_to_index, and I needed to add a third file. I factored this pattern in a separate class, index_wip_file. - It became a bit tedious to keep the call to assert_file_size in write_psymtabs_to_index, write_gdbindex would have had to return two sizes. Instead, I moved the calls to assert_file_size where the file is written. The downside is that we lose the filename at this point, but it was only used for the very improbable case of ftell failing, so I think it's not a problem. - The actual writing of the index file is factored out to write_gdbindex_1, so it can be re-used for both index files. - While the "save gdb-index" command will now write two .gdb-index files, this patch does not update the gdb-add-index.sh script, this will come in a later patch. ... --=20 You are receiving this mail because: You are on the CC list for the bug.=