From: John Baldwin <jhb@FreeBSD.org>
To: Tom Tromey <tom@tromey.com>, gdb-patches@sourceware.org
Subject: Re: [PATCH 00/29] Restructure symbol domains
Date: Tue, 21 Nov 2023 10:37:55 -0800 [thread overview]
Message-ID: <989a3dbb-0337-419a-83b7-122104826580@FreeBSD.org> (raw)
In-Reply-To: <20231120-submit-domain-hacks-2-v1-0-29650d01b198@tromey.com>
On 11/20/23 7:53 PM, Tom Tromey wrote:
> gdb's symbol domains have long needed some restructuring.
>
> The current symbol domains are C-centric, with the "struct" domain
> being separate from types (which is not the case in non-C languages)
> and function and types being lumped in with variables. This latter
> decision makes it impossible to search the symbol table for a
> function, resulting in bugs like PR 30158, where "main" was found as a
> namespace, causing a crash.
>
> This series adds new symbol domains for types and functions, and
> changes the various symbol-lookup functions to allow multiple domains
> to be searched at once.
>
> Then, the symbol readers are changed to use the new domains.
>
> Finally, selected bits of code are changed to be more precise in which
> domains they search.
>
> symbol_matches_domain currently has a C++-specific hack. This hack
> handles the C++ language rule where a tag is also entered as a
> typedef. While working on this series, I discovered that the
> non-DWARF symbol readers will actually emit a second typedef symbol.
> DWARF could do this as well, at some memory expense; and while I
> consider this to be cleaner in an abstract way, for the time being
> I've left the hack in place.
>
> I regression tested this on x86-64 Fedora 38. I also regression
> tested using the debug-names and gdb-index target boards.
I did not look at this all in detail, but I did review 1-7 close enough
to add 'Reviewed-by'. I think the idea in general is sensible though,
and certainly I think it can be helpful even when working with C to
restrict searches by type (e.g. "only functions").
As far as I understand it, I do agree that changing the DWARF reader to
emit duplicate typedef symbols for C++ probably is the cleaner long term
solution compared to the current hacks.
--
John Baldwin
prev parent reply other threads:[~2023-11-21 18:37 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-11-21 3:53 Tom Tromey
2023-11-21 3:53 ` [PATCH 01/29] Fix bug in cooked index scanner Tom Tromey
2023-11-21 3:53 ` [PATCH 02/29] Small cleanup in DWARF reader Tom Tromey
2023-11-21 3:53 ` [PATCH 03/29] Make nsalias.exp more reliable Tom Tromey
2023-11-21 3:53 ` [PATCH 04/29] Fix latent bug in mdebugread.c Tom Tromey
2023-11-21 3:53 ` [PATCH 05/29] Give names to unspecified types Tom Tromey
2023-11-21 3:53 ` [PATCH 06/29] Remove NR_DOMAINS Tom Tromey
2023-11-21 3:53 ` [PATCH 07/29] Simplify symbol_to_info_string Tom Tromey
2023-11-21 3:53 ` [PATCH 08/29] Split up a big 'if' in symtab.c Tom Tromey
2023-11-21 3:53 ` [PATCH 09/29] Use a .def file for domain_enum Tom Tromey
2023-11-21 3:53 ` [PATCH 10/29] Add two new symbol domains Tom Tromey
2023-11-21 3:53 ` [PATCH 11/29] Add domain_search_flags Tom Tromey
2023-11-21 3:53 ` [PATCH 12/29] Replace search_domain with domain_search_flags Tom Tromey
2023-11-21 3:53 ` [PATCH 13/29] Remove a check of VAR_DOMAIN Tom Tromey
2023-11-21 3:53 ` [PATCH 14/29] Introduce "scripting" domains Tom Tromey
2023-11-21 3:53 ` [PATCH 15/29] Use domain_search_flags in lookup_global_symbol_language Tom Tromey
2023-11-21 3:53 ` [PATCH 16/29] Use domain_search_flags in lookup_symbol et al Tom Tromey
2023-11-21 3:53 ` [PATCH 17/29] Remove some obsolete Python constants Tom Tromey
2023-11-21 3:53 ` [PATCH 18/29] Remove old symbol_matches_domain Tom Tromey
2023-11-21 3:53 ` [PATCH 19/29] Use the new symbol domains Tom Tromey
2023-11-21 3:53 ` [PATCH 20/29] Simplify some symbol searches in Ada code Tom Tromey
2023-11-21 3:53 ` [PATCH 21/29] Simplify some symbol searches in linespec.c Tom Tromey
2023-11-21 3:53 ` [PATCH 22/29] Only search for "main" as a function Tom Tromey
2023-11-21 3:53 ` [PATCH 23/29] Only look for functions in expand_symtabs_for_function Tom Tromey
2023-11-21 3:53 ` [PATCH 24/29] Use a function-domain search in inside_main_func Tom Tromey
2023-11-21 3:53 ` [PATCH 25/29] Only search types in cp_lookup_rtti_type Tom Tromey
2023-11-21 3:53 ` [PATCH 26/29] Only search types in lookup_typename Tom Tromey
2023-11-21 3:53 ` [PATCH 27/29] Only search for functions in rust_structop::evaluate_funcall Tom Tromey
2023-11-21 3:53 ` [PATCH 28/29] Refine search in cp_search_static_and_baseclasses Tom Tromey
2023-11-21 3:54 ` [PATCH 29/29] Document new Python and Guile constants Tom Tromey
2023-11-21 11:39 ` Eli Zaretskii
2024-01-23 0:34 ` Tom Tromey
2024-01-23 18:11 ` Eli Zaretskii
2023-11-21 18:37 ` John Baldwin [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=989a3dbb-0337-419a-83b7-122104826580@FreeBSD.org \
--to=jhb@freebsd.org \
--cc=gdb-patches@sourceware.org \
--cc=tom@tromey.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).