Bug 25834 - [cc-with-gdb-index,cc-with-debug-names] FAIL: gdb.dwarf2/dup-psym.exp: info sources should contain only one reference to file1.txt (file1.txt seen more than once)
Summary: [cc-with-gdb-index,cc-with-debug-names] FAIL: gdb.dwarf2/dup-psym.exp: info s...
Status: RESOLVED FIXED
Alias: None
Product: gdb
Classification: Unclassified
Component: symtab (show other bugs)
Version: HEAD
: P2 normal
Target Milestone: ---
Assignee: Tom Tromey
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2020-04-16 08:26 UTC by Tom de Vries
Modified: 2022-05-07 15:41 UTC (History)
2 users (show)

See Also:
Host:
Target:
Build:
Last reconfirmed:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Tom de Vries 2020-04-16 08:26:04 UTC
This looks like a regression, used to pass at gdb-8.3-branch branchpoint.
Comment 1 Tom de Vries 2020-04-16 09:52:46 UTC
Test-case is for patch: https://sourceware.org/legacy-ml/gdb-patches/2004-10/msg00298.html
Comment 2 Tom de Vries 2020-04-16 10:42:46 UTC
Bisects to:

commit aa3916548076c159ae00a922690694094a37fcd0
Author: Tom Tromey <tromey@adacore.com>
Date:   Thu Jul 18 12:27:16 2019 -0600

    Fix latent bug in .debug_names file-name handling
    
    An internal Ada test case showed that the .debug_names code does not
    compute the same list of file names as the partial symbol reader.  In
    particular, the partial symbol reader uses the DW_AT_name of the CU:
    
      /* Allocate a new partial symbol table structure.  */
      filename = dwarf2_string_attr (comp_unit_die, DW_AT_name, cu);
      if (filename == NULL)
        filename = "";
    
      pst = create_partial_symtab (per_cu, filename);
    
    This patch changes the .debug_names reader to follow.
    
    gdb/ChangeLog
    2019-09-10  Tom Tromey  <tromey@adacore.com>
    
            * dwarf2read.c (dw2_get_file_names_reader): Add the
            CU's file name to the results.
    
    gdb/testsuite/ChangeLog
    2019-09-10  Tom Tromey  <tromey@adacore.com>
    
            * gdb.ada/dgopt.exp: New file.
            * gdb.ada/dgopt/x.adb: New file.
Comment 4 Sourceware Commits 2021-07-17 17:18:03 UTC
The master branch has been updated by Tom Tromey <tromey@sourceware.org>:

https://sourceware.org/git/gitweb.cgi?p=binutils-gdb.git;h=1fd5fd5817dee816f30d0573b2d0ca1affb62836

commit 1fd5fd5817dee816f30d0573b2d0ca1affb62836
Author: Tom Tromey <tom@tromey.com>
Date:   Sun Jul 4 13:48:33 2021 -0600

    Fix file-name handling regression with DWARF index
    
    When run with the gdb-index or debug-names target boards, dup-psym.exp
    fails.  This came up for me because my new DWARF scanner reuses this
    part of the existing index code, and so it registers as a regression.
    This is PR symtab/25834.
    
    Looking into this, I found that the DWARF index code here is fairly
    different from the psymtab code.  I don't think there's a deep reason
    for this, and in fact, it seemed to me that the index code could
    simply mimic what the psymtab code already does.
    
    That is what this patch implements.  The DW_AT_name and DW_AT_comp_dir
    are now stored in the quick file names table.  This may require
    allocating a quick file names table even when DW_AT_stmt_list does not
    exist.  Then, the functions that work with this data are changed to
    use find_source_or_rewrite, just as the psymbol code does.  Finally,
    line_header::file_full_name is removed, as it is no longer needed.
    
    Currently, the index maintains a hash table of "quick file names".
    The hash table uses a deletion function to free the "real name"
    components when necessary.  There's also a second such function to
    implement the forget_cached_source_info method.
    
    This bug fix patch will create a quick file name object even when
    there is no DW_AT_stmt_list, meaning that the object won't be entered
    in the hash table.  So, this patch changes the memory management
    approach so that the entries are cleared when the per-BFD object is
    destroyed.  (A dwarf2_per_cu_data destructor is not introduced,
    because we have been avoiding adding a vtable to that class.)
    
    Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=25834
Comment 5 Tom Tromey 2022-05-07 15:41:22 UTC
I think this was fixed a while ago but I forgot to close it.