public inbox for gdb-prs@sourceware.org help / color / mirror / Atom feed
From: "vries at gcc dot gnu.org" <sourceware-bugzilla@sourceware.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 [thread overview] Message-ID: <bug-30841-4717-vonA4c5aIk@http.sourceware.org/bugzilla/> (raw) In-Reply-To: <bug-30841-4717@http.sourceware.org/bugzilla/> https://sourceware.org/bugzilla/show_bug.cgi?id=30841 --- Comment #2 from Tom de Vries <vries at gcc dot gnu.org> --- (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 <simon.marchi@polymtl.ca> 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 the resulting index (with readelf --debug-dump=gdb_index), we can see something 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. ... -- You are receiving this mail because: You are on the CC list for the bug.
next prev parent reply other threads:[~2023-09-12 16:25 UTC|newest] Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top 2023-09-12 9:41 [Bug symtab/30841] New: [gdb, symtab] gdb-add-index doesn't support .gnu_debugaltlink vries at gcc dot gnu.org 2023-09-12 9:42 ` [Bug symtab/30841] [gdb, symtab] support .gnu_debugaltlink in gdb-add-index vries at gcc dot gnu.org 2023-09-12 15:46 ` tromey at sourceware dot org 2023-09-12 16:25 ` vries at gcc dot gnu.org [this message] 2023-09-13 3:18 ` sam at gentoo dot org 2023-09-13 6:53 ` vries at gcc dot gnu.org
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=bug-30841-4717-vonA4c5aIk@http.sourceware.org/bugzilla/ \ --to=sourceware-bugzilla@sourceware.org \ --cc=gdb-prs@sourceware.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).