diff options
author | Tom Tromey <tom@tromey.com> | 2025-05-08 14:04:05 -0600 |
---|---|---|
committer | Tom Tromey <tom@tromey.com> | 2025-05-23 08:48:18 -0600 |
commit | 8d13d83aba4a103959b127cbb5666e28667ac338 (patch) | |
tree | ca1f9155c6bc09b5fa794204c1e60d7b6f67d331 /gdb/make-init-c | |
parent | 14303d6295e1bfd8a4e1b447057b78ce583be75d (diff) | |
download | binutils-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