diff options
| author | Tom Tromey <tom@tromey.com> | 2020-04-24 15:35:01 -0600 |
|---|---|---|
| committer | Tom Tromey <tromey@adacore.com> | 2020-04-24 15:35:03 -0600 |
| commit | bcfe6157ca288efed127c5efe21ad7924e0d98cf (patch) | |
| tree | 8f8ca201e90f3f40fce5bde8202e0fea5ab1da9c /gdb/compile | |
| parent | f049a313fcad4d51a55b6e635612c98e1a72b8a8 (diff) | |
| download | gdb-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/compile')
| -rw-r--r-- | gdb/compile/compile-object-load.c | 7 |
1 files changed, 4 insertions, 3 deletions
diff --git a/gdb/compile/compile-object-load.c b/gdb/compile/compile-object-load.c index 3fe9518..be4fa76 100644 --- a/gdb/compile/compile-object-load.c +++ b/gdb/compile/compile-object-load.c @@ -402,6 +402,9 @@ get_out_value_type (struct symbol *func_sym, struct objfile *objfile, int nblocks = 0; int block_loop = 0; + lookup_name_info func_matcher (GCC_FE_WRAPPER_FUNCTION, + symbol_name_match_type::SEARCH_NAME); + bv = SYMTAB_BLOCKVECTOR (func_sym->owner.symtab); nblocks = BLOCKVECTOR_NBLOCKS (bv); @@ -433,9 +436,7 @@ get_out_value_type (struct symbol *func_sym, struct objfile *objfile, if (function != NULL && (BLOCK_SUPERBLOCK (function_block) == BLOCKVECTOR_BLOCK (bv, STATIC_BLOCK)) - && (strcmp_iw (function->linkage_name (), - GCC_FE_WRAPPER_FUNCTION) - == 0)) + && symbol_matches_search_name (function, func_matcher)) break; } if (block_loop == nblocks) |