[Bug symtab/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)

["cvs-commit at gcc dot gnu.org" <sourceware-bugzilla@sourceware.org>]

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

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

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