aboutsummaryrefslogtreecommitdiff
path: root/gdb/testsuite/gdb.python
diff options
context:
space:
mode:
authorTom Tromey <tom@tromey.com>2020-04-24 15:35:01 -0600
committerTom Tromey <tromey@adacore.com>2020-04-24 15:35:03 -0600
commitbcfe6157ca288efed127c5efe21ad7924e0d98cf (patch)
tree8f8ca201e90f3f40fce5bde8202e0fea5ab1da9c /gdb/testsuite/gdb.python
parentf049a313fcad4d51a55b6e635612c98e1a72b8a8 (diff)
downloadgdb-bcfe6157ca288efed127c5efe21ad7924e0d98cf.zip
gdb-bcfe6157ca288efed127c5efe21ad7924e0d98cf.tar.gz
gdb-bcfe6157ca288efed127c5efe21ad7924e0d98cf.tar.bz2
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.
Diffstat (limited to 'gdb/testsuite/gdb.python')
-rw-r--r--gdb/testsuite/gdb.python/py-symbol.exp2
1 files changed, 1 insertions, 1 deletions
diff --git a/gdb/testsuite/gdb.python/py-symbol.exp b/gdb/testsuite/gdb.python/py-symbol.exp
index c4bae9f..caa7ddc 100644
--- a/gdb/testsuite/gdb.python/py-symbol.exp
+++ b/gdb/testsuite/gdb.python/py-symbol.exp
@@ -211,7 +211,7 @@ gdb_test "python print (cplusfunc.is_function)" \
gdb_test "python print (cplusfunc.name)" "SimpleClass::valueofi().*" "test method.name"
gdb_test "python print (cplusfunc.print_name)" "SimpleClass::valueofi().*" "test method.print_name"
-gdb_test "python print (cplusfunc.linkage_name)" "SimpleClass::valueofi().*" "test method.linkage_name"
+gdb_test "python print (cplusfunc.linkage_name)" "_ZN11SimpleClass8valueofiEv.*" "test method.linkage_name"
gdb_test "python print (cplusfunc.addr_class == gdb.SYMBOL_LOC_BLOCK)" "True" "test method.addr_class"
# Test is_valid when the objfile is unloaded. This must be the last