[ Filed earlier as "[RFC] How to fix gdb.dwarf2/main-subprogram.exp with cc-with-gdb-index/cc-with-debug-names" ( https://sourceware.org/ml/gdb-patches/2019-05/msg00157.html ). ] DW_AT_main_subprogram is supported in normal mode (in read_partial_die), and tested by test-case gdb.dwarf2/main-subprogram.exp. DW_AT_main_subprogram is currently not supported in -readnow mode, but I've submitted a fix for that (in read_func_scope) see PR24517 - "DW_AT_main_subprogram ignored with readnow". Still, the test-case gdb.dwarf2/main-subprogram.exp fails with executables that contain an index, either .gdb_index or .debug_names (which is exercised by target boards cc-with-gdb-index and cc-with-debug-names). The test-case does not contain a DW_AT_main_subprogram in the compilation unit DIE, as it should. The test-case needs to be fixed up, and likewise gcc ( gcc#90422 - "DW_AT_main_subprogram not added to CU DIE" ( https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90422 )). But even with the test-case fixed, gdb does not handle the DW_AT_main_subprogram in the CU DIE.
Hmm, this looks worse than I thought. This is not specific to using the start command. When we load a file, we want to known the initial language, which we set based on ... the main symbol.
If we want it to work with index files, I guess the index format will need to be changed to include this flag, won't it?
(In reply to Simon Marchi from comment #2) > If we want it to work with index files, I guess the index format will need > to be changed to include this flag, won't it? In absence of the GCC bug fix, it's in principle possible to fix this in GDB by scanning all CUs until a DW_TAG_subprogram DIE with DW_AT_main_subprogram flag is found, but that might take a lot of time, and I imagine it will reduce the usefulness of the index to a point that it makes more sense to extend the index format. Assuming that the GCC bug is fixed, it's possible to fix this in GDB by scanning only the CU attributes for each CU to find the DW_AT_main_subprogram attribute flag. Then if found, scan the CU itself to find the actual DW_TAG_subprogram DIE with DW_AT_main_subprogram flag. If that CU is large, that will still take time to scan, so having this information available in the index would speed that up. So I'd say, agreed, adding this info to index files is a good idea.
The master branch has been updated by Tom de Vries <vries@sourceware.org>: https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=a22ec6e8a4b9006e342ad20c36357a5ba8ba1e74 commit a22ec6e8a4b9006e342ad20c36357a5ba8ba1e74 Author: Tom de Vries <tdevries@suse.de> Date: Fri Feb 5 10:56:39 2021 +0100 [gdb/testsuite] Add KFAILs for PR symtab/24549 When an executable contains an index such as a .gdb_index or .debug_names section, gdb ignores the DW_AT_subprogram attribute. This problem has been filed as PR symtab/24549. Add KFAILs for this PR in test-cases gdb.dwarf2/main-subprogram.exp and gdb.fortran/mixed-lang-stack.exp. Tested on x86_64-linux. gdb/testsuite/ChangeLog: 2021-02-05 Tom de Vries <tdevries@suse.de> * gdb.dwarf2/main-subprogram.exp: Add KFAIL for PR symtab/24549. * gdb.fortran/mixed-lang-stack.exp: Same.
Filed RFC to fix this in .debug_names: https://sourceware.org/pipermail/gdb-patches/2021-February/175862.html
See also bug #13795.
I think this is the current leading idea for a fix: https://sourceware.org/pipermail/gdb-patches/2021-March/176709.html
gdb-index solution: https://sourceware.org/pipermail/gdb-patches/2023-August/201568.html
The master branch has been updated by Tom de Vries <vries@sourceware.org>: https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=8b9c08eddac038663b8f5ede4b4d24e441a6d8a3 commit 8b9c08eddac038663b8f5ede4b4d24e441a6d8a3 Author: Matheus Branco Borella <dark.ryu.550@gmail.com> Date: Tue Oct 10 10:26:40 2023 +0200 [gdb/symtab] Add name_of_main and language_of_main to the DWARF index This patch adds a new section to the DWARF index containing the name and the language of the main function symbol, gathered from `cooked_index::get_main`, if available. Currently, for lack of a better name, this section is called the "shortcut table". The way this name is both saved and applied upon an index being loaded in mirrors how it is done in `cooked_index_functions`, more specifically, the full name of the main function symbol is saved and `set_objfile_main_name` is used to apply it after it is loaded. The main use case for this patch is in improving startup times when dealing with large binaries. Currently, when an index is used, GDB has to expand symtabs until it finds out what the language of the main function symbol is. For some large executables, this may take a considerable amount of time to complete, slowing down startup. This patch bypasses that operation by having both the name and language of the main function symbol be provided ahead of time by the index. In my testing (a binary with about 1.8GB worth of DWARF data) this change brings startup time down from about 34 seconds to about 1.5 seconds. When testing the patch with target board cc-with-gdb-index, test-case gdb.fortran/nested-funcs-2.exp starts failing, but this is due to a pre-existing issue, filed as PR symtab/30946. Tested on x86_64-linux, with target board unix and cc-with-gdb-index. PR symtab/24549 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=24549 Approved-By: Tom de Vries <tdevries@suse.de>
My .debug_names rewrite fixes this.
https://sourceware.org/pipermail/gdb-patches/2023-December/204949.html
The master branch has been updated by Tom Tromey <tromey@sourceware.org>: https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=91a42a618085f236c5f6527322f88044e7550a63 commit 91a42a618085f236c5f6527322f88044e7550a63 Author: Tom Tromey <tom@tromey.com> Date: Sun Dec 3 18:20:37 2023 -0700 Rewrite .debug_names writer This rewrites GDB's .debug_names writer. It is now closer to the form imagined in the DWARF spec. In particular, names are emitted exactly as they appear in the original DWARF. In order to make the reader work nicely, some extensions were needed. These were all documented in an earlier patch. Note that in particular this writer solves the "main name" problem by putting a flag into the table. GDB does not use the .debug_names hash table, so it also does not write one. I consider this hash table to be essentially useless in general, due to the name canonicalization problem -- while DWARF says that writers should use the system demangling style, (1) this style varies across systems, so it can't truly be relied on; and (2) at least GCC and one other compiler don't actually follow this part of the spec anyway. It's important to note, though, that even if the hash was somehow useful, GDB probably still would not use it -- a sorted list of names is needed for completion and performs reasonably well for other lookups, so a hash table is just overhead, IMO. String emission is also simplified. There's no need in this writer to ingest the contents of .debug_str. A couple of tests are updated to reflect the fact that they now "fail" because the tests don't include .debug_aranges in the .S file. Arguably the .debug_names writer should also create this section; but I did not implement that in this series, and there is a separate bug about it. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=24820 Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=24549
Fixed in .debug_names as well now.