Consider test-case gdb.fortran/nested-funcs-2.exp. It runs fine with target board unix, and also when using target board cc-with-gdb-index. But the latter is somewhat deceptive. With target board unix: ... $ gdb -q -batch \ -iex "set trace-commands on" \ nested-funcs-2 \ -ex "maint info symtabs" \ -ex "info symbol contains_keyword::increment" +maint info symtabs +info symbol contains_keyword::increment increment in section .text ... we start from a position where no symtab is expanded. But with cc-with-gdb-index, we start from a position where the only relevant symtab is already expanded: ... +maint info symtabs ... name nested-funcs-2.f90 ... +info symbol contains_keyword::increment increment in section .text ... What happens is that when loading the exec, gdb attempts to auto-detect the language and/or name of the main function. In the target-board unix case, the cooked index is used to answer this question, and no symtab expansion happens. When doing the symbol lookup, the correct symtab is expanded, and the result is found in the expanded symtab. In the target-board cc-with-gdb-index case, it results in the expansion of the symtab, which means that the test-case is not actually testing that symtab expansion is properly triggered by the symbol lookup. We can prevent the early expansion by hard-coding the language: ... $ gdb -q -batch \ -iex "set trace-commands on" \ -iex "set lang fortran" \ nested-funcs-2 \ -ex "maint info symtabs" \ -ex "info symbol contains_keyword::increment" +set lang fortran +maint info symtabs +info symbol contains_keyword::increment No symbol "contains_keyword::increment" in current context. ... and that exposes that the functionality doesn't work. We can demonstrate the same when running the test-case by applying this demonstrator patch: ... diff --git a/gdb/testsuite/gdb.fortran/nested-funcs-2.exp b/gdb/testsuite/gdb.fortran/nested-funcs-2.exp index 8c3b61aa161..6fb4899ee5b 100644 --- a/gdb/testsuite/gdb.fortran/nested-funcs-2.exp +++ b/gdb/testsuite/gdb.fortran/nested-funcs-2.exp @@ -32,11 +32,13 @@ set int4 [fortran_int4] # nested subroutine symbols will be prefixed with their parent # subroutine scope. proc do_bp_tests {with_src_prefix_p with_nest_prefix_p} { - global testfile srcfile + global binfile srcfile global int4 global hex - clean_restart ${testfile} + clean_restart + gdb_test "set lang fortran" + gdb_load $binfile if { $with_src_prefix_p } { set src_prefix "${srcfile}:" ... which gets us these FAILs: ... Running /data/vries/gdb/src/gdb/testsuite/gdb.fortran/nested-funcs-2.exp ... FAIL: gdb.fortran/nested-funcs-2.exp: src_prefix=0: nest_prefix=1: before start: info symbol contains_keyword::increment FAIL: gdb.fortran/nested-funcs-2.exp: src_prefix=0: nest_prefix=1: before start: whatis contains_keyword::increment FAIL: gdb.fortran/nested-funcs-2.exp: src_prefix=0: nest_prefix=1: before start: ptype contains_keyword::increment FAIL: gdb.fortran/nested-funcs-2.exp: src_prefix=0: nest_prefix=1: before start: print contains_keyword::increment FAIL: gdb.fortran/nested-funcs-2.exp: src_prefix=1: nest_prefix=1: before start: info symbol contains_keyword::increment FAIL: gdb.fortran/nested-funcs-2.exp: src_prefix=1: nest_prefix=1: before start: whatis contains_keyword::increment FAIL: gdb.fortran/nested-funcs-2.exp: src_prefix=1: nest_prefix=1: before start: ptype contains_keyword::increment FAIL: gdb.fortran/nested-funcs-2.exp: src_prefix=1: nest_prefix=1: before start: print contains_keyword::increment ... The patch "[gdb/symtab] Add name_of_main and language_of_main to the DWARF index" ( https://sourceware.org/pipermail/gdb-patches/2023-August/201568.html ) also prevents the early expansion mentioned above, and applying it makes this test-case fail in the same way, without the demonstrator patch (which is how I found this in the first place).
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>
FWIW this test works fine with my .debug_names rewrite, even with the demonstrator patch applied. And 'maint info symtabs' shows that nothing is pre-expanded. For me this is a bit mysterious in that I'd expect the results to be similar for .gdb_index.