aboutsummaryrefslogtreecommitdiff
path: root/gdb/make-init-c
diff options
context:
space:
mode:
authorTom Tromey <tom@tromey.com>2025-05-08 14:04:05 -0600
committerTom Tromey <tom@tromey.com>2025-05-23 08:48:18 -0600
commit8d13d83aba4a103959b127cbb5666e28667ac338 (patch)
treeca1f9155c6bc09b5fa794204c1e60d7b6f67d331 /gdb/make-init-c
parent14303d6295e1bfd8a4e1b447057b78ce583be75d (diff)
downloadbinutils-8d13d83aba4a103959b127cbb5666e28667ac338.zip
binutils-8d13d83aba4a103959b127cbb5666e28667ac338.tar.gz
binutils-8d13d83aba4a103959b127cbb5666e28667ac338.tar.bz2
Handle an argument-less operator in the C++ name parser
While debugging a new failure in my long-suffering "search-in-psyms" series, I found that the C++ name canonicalizer did not handle a case like "some_name::operator new []". This should remove the space, resulting in "some_name::operator new[]" -- but does not. This happens because the parser requires an operator to be followed by argument types. That is, it's expected. However, it seems to me that we do want to be able to canonicalize a name like this. It will appear in the DWARF as a DW_AT_name, and furthermore it could be entered by the user. This patch fixes this problem by changing the grammar to supply the "()" itself, then removing the trailing "()" when changing to string form (in the functions that matter). This isn't ideal -- it might miss a very obscure case involving the gdb extension of providing fully-qualified names for function-local statics -- but it improves the situation at least. It's possible a better solution might be to rewrite the name canonicalizer. I was wondering if this could perhaps be done without reference to the grammar -- just by examining the tokens. However, that's much more involved. Let me know what you think. Regression tested on x86-64 Fedora 40. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=32939 Reviewed-By: Keith Seitz <keiths@redhat.com>
Diffstat (limited to 'gdb/make-init-c')
0 files changed, 0 insertions, 0 deletions