aboutsummaryrefslogtreecommitdiff
path: root/gdb/async-event.h
diff options
context:
space:
mode:
authorTom Tromey <tom@tromey.com>2025-02-21 09:18:28 -0700
committerTom Tromey <tom@tromey.com>2025-03-07 17:15:20 -0700
commitaab2ac34d7f78f0b7a42cef0187dc6e4d7ec4f02 (patch)
tree3fa71586b82374b5d2cb0a24ff5fd998ecbc1044 /gdb/async-event.h
parentd519282866163864fff3fe0ab7227ff0339cad67 (diff)
downloadbinutils-aab2ac34d7f78f0b7a42cef0187dc6e4d7ec4f02.zip
binutils-aab2ac34d7f78f0b7a42cef0187dc6e4d7ec4f02.tar.gz
binutils-aab2ac34d7f78f0b7a42cef0187dc6e4d7ec4f02.tar.bz2
Avoid excessive CU expansion on failed matches
PR symtab/31010 points out that something like "ptype INT" will expand all CUs in a typical program. The OP further points out that the original patch for PR symtab/30520: https://sourceware.org/pipermail/gdb-patches/2024-January/205924.html ... did solve the problem, but the patch changed after (my) review and reintroduced the bug. In cooked_index_functions::expand_symtabs_matching, the final component of a split name is compared with the entry's name using the usual method of calling get_symbol_name_matcher. This code iterates over languages and tries to split the original name according to each style. But, the Ada splitter uses the decoded name -- "int". This causes every C or C++ CU to be expanded. Clearly this is wrong. And, it seems to me that looping over languages and trying to guess the splitting style for the input text is probably bad. However, fixing the problem is not so easy (again due to Ada). I've filed a follow-up bug, PR symtab/32733, for this. Meanwhile, this patch changes the code to be closer to the originally-submitted patch. This works because the comparison is now done between the full name and the "lookup_name_without_params" object, which is a less adulterated variant of the original input. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=31010 Tested-By: Simon Marchi <simon.marchi@efficios.com>
Diffstat (limited to 'gdb/async-event.h')
0 files changed, 0 insertions, 0 deletions