[Bug symtab/12707] physname regression: set print demangle off

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

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

--- Comment #11 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=bcfe6157ca288efed127c5efe21ad7924e0d98cf

commit bcfe6157ca288efed127c5efe21ad7924e0d98cf
Author: Tom Tromey <tom@tromey.com>
Date:   Fri Apr 24 15:35:01 2020 -0600

    Use the linkage name if it exists

    The DWARF reader has had some odd code since the "physname" patches landed.

    In particular, these patches caused PR symtab/12707; namely, they made
    it so "set print demangle off" no longer works.

    This patch attempts to fix the problem.  It arranges to store the
    linkage name on the symbol if it exists, and it changes the DWARF
    reader so that the demangled name is no longer (usually) stored in the
    symbol's "linkage name" field.

    c-linkage-name.exp needed a tweak, because it started working
    correctly.  This conforms to what I think ought to happen, so this
    seems like an improvement here.

    compile-object-load.c needed a small change to use
    symbol_matches_search_name rather than directly examining the linkage
    name.  Looking directly at the name does the wrong thing for C++.

    There is still some name-related confusion in the DWARF reader:

    * "physname" often refers to the logical name and not what I would
      consider to be the "physical" name;

    * dwarf2_full_name, dwarf2_name, and dwarf2_physname all exist and
      return different strings -- but this seems like at least one name
      too many.  For example, Fortran requires dwarf2_full_name, but other
      languages do not.

    * To my surprise, dwarf2_physname prefers the form emitted by the
      demangler over the one that it computes.  This seems backward to me,
      given that the partial symbol reader prefers the opposite, and it
      seems to me that this choice may perform better as well.

    I didn't attempt to clean up these things.  It would be good to do,
    but whenever I contemplate it I get caught up in dreams of truly
    rewriting the DWARF reader instead.

    gdb/ChangeLog
    2020-04-24  Tom Tromey  <tom@tromey.com>

            PR symtab/12707:
            * dwarf2/read.c (add_partial_symbol): Use the linkage name if it
            exists.
            (new_symbol): Likewise.
            * compile/compile-object-load.c (get_out_value_type): Use
            symbol_matches_search_name.

    gdb/testsuite/ChangeLog
    2020-04-24  Tom Tromey  <tom@tromey.com>

            PR symtab/12707:
            * gdb.python/py-symbol.exp: Update expected results for
            linkage_name test.
            * gdb.cp/print-demangle.exp: New file.
            * gdb.base/c-linkage-name.exp: Fix test.
            * gdb.guile/scm-symbol.exp: Update expected results for
            linkage_name test.

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