[Bug gdb/25663] dwarf2_name caching bug

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

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

--- Comment #10 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=67430cd00afcc270a27e44b10f9ef4249d554e66

commit 67430cd00afcc270a27e44b10f9ef4249d554e66
Author: Tom Tromey <tromey@adacore.com>
Date:   Mon Mar 16 15:00:52 2020 -0600

    Fix dwarf2_name caching bug

    PR gdb/25663 points out that dwarf2_name will cache a value in the
    bcache and then return a substring.  However, this substring return is
    only done on the branch that caches the value -- so if the function is
    called twice with the same arguments, it will return different values.

    This patch fixes this problem.

    This area is strange.  We cache the entire demangled string, but only
    return the suffix.  I looked at caching just the suffix, but it turns
    out that anonymous_struct_prefix assumes that the entire string is
    stored.  Also weird is that this code is demangling the linkage name
    and then storing the demangled form back into the linkage name
    attribute -- that seems bad, because what if some code wants to find
    the actual linkage name?

    Fixing these issues was non-trivial, though; and in the meantime this
    patch seems like an improvement.  Regression tested on x86-64
    Fedora 30.

    gdb/ChangeLog
    2020-03-16  Tom Tromey  <tromey@adacore.com>

            PR gdb/25663:
            * dwarf2/read.c (dwarf2_name): Strip leading namespaces after
            putting value into bcache.

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