[Bug symtab/30946] New: [gdb/symtab, gdb-index] FAIL: gdb.fortran/nested-funcs-2.exp: src_prefix=0: nest_prefix=1: before start: info symbol contains_keyword::increment

[Bug symtab/30946] New: [gdb/symtab, gdb-index] FAIL: gdb.fortran/nested-funcs-2.exp: src_prefix=0: nest_prefix=1: before start: info symbol contains_keyword::increment

[vries at gcc dot gnu.org]

https://sourceware.org/bugzilla/show_bug.cgi?id=30946

            Bug ID: 30946
           Summary: [gdb/symtab, gdb-index] FAIL:
                    gdb.fortran/nested-funcs-2.exp: src_prefix=0:
                    nest_prefix=1: before start: info symbol
                    contains_keyword::increment
           Product: gdb
           Version: HEAD
            Status: NEW
          Severity: normal
          Priority: P2
         Component: symtab
          Assignee: unassigned at sourceware dot org
          Reporter: vries at gcc dot gnu.org
  Target Milestone: ---

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).

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug symtab/30946] [gdb/symtab, gdb-index] FAIL: gdb.fortran/nested-funcs-2.exp: src_prefix=0: nest_prefix=1: before start: info symbol contains_keyword::increment

[cvs-commit at gcc dot gnu.org]

https://sourceware.org/bugzilla/show_bug.cgi?id=30946

--- Comment #1 from cvs-commit at gcc dot gnu.org <cvs-commit at gcc dot gnu.org> ---
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>

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug symtab/30946] [gdb/symtab, gdb-index] FAIL: gdb.fortran/nested-funcs-2.exp: src_prefix=0: nest_prefix=1: before start: info symbol contains_keyword::increment

[tromey at sourceware dot org]

https://sourceware.org/bugzilla/show_bug.cgi?id=30946

Tom Tromey <tromey at sourceware dot org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |tromey at sourceware dot org

--- Comment #2 from Tom Tromey <tromey at sourceware dot org> ---
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.

-- 
You are receiving this mail because:
You are on the CC list for the bug.