mirror of
https://github.com/espressif/binutils-gdb.git
synced 2025-06-22 02:50:08 +08:00
bcfe6157ca
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.
README for GNU development tools This directory contains various GNU compilers, assemblers, linkers, debuggers, etc., plus their support routines, definitions, and documentation. If you are receiving this as part of a GDB release, see the file gdb/README. If with a binutils release, see binutils/README; if with a libg++ release, see libg++/README, etc. That'll give you info about this package -- supported targets, how to use it, how to report bugs, etc. It is now possible to automatically configure and build a variety of tools with one command. To build all of the tools contained herein, run the ``configure'' script here, e.g.: ./configure make To install them (by default in /usr/local/bin, /usr/local/lib, etc), then do: make install (If the configure script can't determine your type of computer, give it the name as an argument, for instance ``./configure sun4''. You can use the script ``config.sub'' to test whether a name is recognized; if it is, config.sub translates it to a triplet specifying CPU, vendor, and OS.) If you have more than one compiler on your system, it is often best to explicitly set CC in the environment before running configure, and to also set CC when running make. For example (assuming sh/bash/ksh): CC=gcc ./configure make A similar example using csh: setenv CC gcc ./configure make Much of the code and documentation enclosed is copyright by the Free Software Foundation, Inc. See the file COPYING or COPYING.LIB in the various directories, for a description of the GNU General Public License terms under which you can copy the files. REPORTING BUGS: Again, see gdb/README, binutils/README, etc., for info on where and how to report problems.