From: Guinevere Larsen <guinevere@redhat.com>
To: Tom Tromey <tom@tromey.com>, gdb-patches@sourceware.org
Subject: Re: [PATCH v2 00/28] Search symbols via quick API
Date: Mon, 28 Apr 2025 11:07:34 -0300 [thread overview]
Message-ID: <f68701da-2a73-47e9-afe1-535b9512e345@redhat.com> (raw)
In-Reply-To: <20250402-search-in-psyms-v2-0-ea91704487cb@tromey.com>
Hi Tromey,
I am having an issue with the quick_fns interface, and while it isn't
affected by this series directly (as I originally thought it could be),
I would appreciate if you could share your expertise on this area. The
TL;DR of the issue is: the quick API seems to be caching something and
searching objfile B for a symbol can return a symbol with details from
objfile A (that was loaded first). I tried looking around for where the
cache could be hidden, but couldn't find it. Do you know if where the
cache is, if it really exists?
Some more context: Now that we have a way to get all solibs (and thus
objfiles) that belong to one namespace, so I'm trying to implement
search for a symbol inside a specific namespace. To do this, I iterate
through objfiles in the selected namespace and use
lookup_symbol_in_objfile on all of them. The first issue I ran into was
the gdb_bfd_cache making the second objfile's symbols not be read, which
I already managed to fix. I know we have correct reading of symbols and
addresses if I follow the dwarf reading, so if symbol lookup was
correct, everything should be working.
Yet, the symbols found through the quick_fns all seem to point to the
same inferior address (I'm unsure if they are different symbols, or the
same symbol returned through dynamic allocation so pointing to different
addresses), meaning that we still effectively only find the first one
and return it. I can verify it by either taking the address directly, or
setting the variable in one namespace and reading it in another.
If you'd like to play around with my changes, I pushed them to the
users/guinevere/symbol_in_linker_namespace branch, and you can use the
test gdb.base/dlmopen-ns-ids to search for the variable gdb_dlmopen_glob
in different namespaces. (gdb.base/dlmopen.exp may not work because I
haven't looked into LOC_UNRESOLVED variables yet, only LOC_STATIC).
--
Cheers,
Guinevere Larsen
She/Her/Hers
On 4/2/25 8:44 PM, Tom Tromey wrote:
> This series changes how symbols are looked up in gdb.
>
> Currently, symbol lookup is done in two phases. In one phase, gdb
> searches all existing symtabs for a symbol. In another phase, gdb
> will call expand_symtabs_matching to expand some symtabs.
>
> Different spots in gdb may order these phases differently -- so some
> places will expand symtabs and then search the compunits, but other
> places will first search expanded symtabs and then use the
> expand_symtabs_matching callback to add further results.
>
> This approach has a few drawbacks.
>
> * The double search means that some discrepancies between the indexer
> and the full reader go unnoticed. This may arguably be a strength
> of the approach, though frequently a carefully crafted test case can
> show this as a bug. Essentially, though, some searches only work by
> accident.
>
> * Searching all expanded symtabs means that, as a debug session drags
> on, searches will examine many irrelevant symtabs.
>
> * In some places, the two phases use different code to perform the
> actual search, meaning that the results can depend on previous CU
> expansion decisions.
>
> * Similarly, if just a single symbol is needed, then both approaches
> are bad: expand-then-search will be unnecessarily inefficient, while
> search-then-expand approach means that the result depends on which
> CUs happen to have already been expanded.
>
> This series changes all of this. Now, all symbol lookups are done via
> the "quick" API, with the idea being that the final search of the
> expanded symtab is done via the expand_symtabs_matching callback.
>
> This fixes all the issues pointed out above:
>
> * Only relevant symtabs are searched, because the index only considers
> matching symbols.
>
> * Some discrepancies between the indexer and the full reader show up
> as symbol lookup failures. Others (if the indexer thinks a symbol
> exists but the full reader does not) will just be inefficient -- but
> we could add a verifier for this.
>
> * Lookups are no longer dependent on symtab expansion state, because
> again the indexer is pre-filtering the matches.
>
> Re-reading the series -- it's been in development for quite a while
> and I've already landed ~20 preliminary patches -- shows that there
> are still a few cleanups in here that could perhaps have gone in
> separately.
>
> Anyway, the essential change is to make the implementations of
> expand_symtabs_matching also call the callback when a symtab has
> already been expanded. After this, most of the work is cleaning up
> individual callers.
>
> This change lead to some surprising places. For example, I had to
> rewrite the .gdb_index reader, because the work done for
> "templates.exp" simply never worked in this mode -- and the test
> obscured the problems, a classic case of lookups working by accident.
>
> I regression tested each patch in this series. Furthermore I
> regression tested the series as a whole using the cc-with-debug-names
> and cc-with-gdb-index target boards. All of this was done on x86-64
> Fedora 40.
>
> I think maybe I've separately submitted "Ada import functions not in
> index" patch. Anyway it's part of this series now.
>
> Signed-off-by: Tom Tromey <tom@tromey.com>
> ---
> Changes in v2:
> - Rebased for all the other recent DWARF changes
> - Link to v1: https://inbox.sourceware.org/gdb-patches/20250311-search-in-psyms-v1-0-d73d9be20983@tromey.com
>
> ---
> Tom Tromey (28):
> Add another minor hack to cooked_index_entry::full_name
> Change ada_decode to preserve upper-case in some situations
> Emit some type declarations in .gdb_index
> Ada import functions not in index
> Fix index's handling of DW_TAG_imported_declaration
> Put all CTF symbols in global scope
> Restore "ingestion" of .debug_str when writing .debug_names
> Entries from anon-struct.exp not in cooked index
> Remove dwarf2_per_cu_data::mark
> Have expand_symtabs_matching work for already-expanded CUs
> Rewrite the .gdb_index reader
> Convert default_collect_symbol_completion_matches_break_on
> Convert gdbpy_lookup_static_symbols
> Convert ada_add_global_exceptions
> Convert ada_language_defn::collect_symbol_completion_matches
> Convert ada-lang.c:map_matching_symbols
> Remove expand_symtabs_matching
> Simplify basic_lookup_transparent_type
> Remove objfile::expand_symtabs_for_function
> Convert linespec.c:iterate_over_all_matching_symtabs
> Simplify block_lookup_symbol_primary
> Pass lookup_name_info to block_lookup_symbol_primary
> Simplify block_lookup_symbol
> Add best_symbol_tracker
> Convert lookup_symbol_via_quick_fns
> Convert lookup_symbol_in_objfile
> Make dw_expand_symtabs_matching_file_matcher static
> Remove enter_symbol_lookup
>
> gdb/ada-lang.c | 221 ++---
> gdb/ada-lang.h | 15 +-
> gdb/block.c | 57 +-
> gdb/block.h | 27 +-
> gdb/cp-support.c | 28 +-
> gdb/ctfread.c | 6 +-
> gdb/dwarf2/abbrev.c | 7 +-
> gdb/dwarf2/abbrev.h | 8 +
> gdb/dwarf2/cooked-index-entry.c | 7 +
> gdb/dwarf2/cooked-index-shard.c | 13 +-
> gdb/dwarf2/cooked-index-shard.h | 7 +
> gdb/dwarf2/cooked-index-worker.h | 17 +-
> gdb/dwarf2/cooked-indexer.c | 37 +-
> gdb/dwarf2/index-write.c | 103 ++-
> gdb/dwarf2/read-gdb-index.c | 1268 ++++++-----------------------
> gdb/dwarf2/read-gdb-index.h | 14 +
> gdb/dwarf2/read.c | 176 ++--
> gdb/dwarf2/read.h | 48 +-
> gdb/dwarf2/tag.h | 12 +
> gdb/linespec.c | 17 +-
> gdb/objfiles.h | 4 -
> gdb/psymtab.c | 3 -
> gdb/python/py-symbol.c | 29 +-
> gdb/symfile-debug.c | 22 -
> gdb/symfile.c | 25 -
> gdb/symfile.h | 9 -
> gdb/symtab.c | 223 ++---
> gdb/symtab.h | 2 +-
> gdb/testsuite/gdb.ada/import.exp | 28 +-
> gdb/testsuite/gdb.ctf/cross-tu-cyclic.exp | 4 +-
> 30 files changed, 861 insertions(+), 1576 deletions(-)
> ---
> base-commit: 60ac9c60fe5b6dc5a59a30a971c3fad020fecf45
> change-id: 20250311-search-in-psyms-3eb1049177e0
>
> Best regards,
next prev parent reply other threads:[~2025-04-28 14:08 UTC|newest]
Thread overview: 50+ messages / expand[flat|nested] mbox.gz Atom feed top
2025-04-02 23:44 Tom Tromey
2025-04-02 23:45 ` [PATCH v2 01/28] Add another minor hack to cooked_index_entry::full_name Tom Tromey
2025-04-02 23:45 ` [PATCH v2 02/28] Change ada_decode to preserve upper-case in some situations Tom Tromey
2025-04-02 23:45 ` [PATCH v2 03/28] Emit some type declarations in .gdb_index Tom Tromey
2025-04-21 2:50 ` Simon Marchi
2025-04-21 14:50 ` Tom Tromey
2025-04-23 4:11 ` Simon Marchi
2025-04-23 20:54 ` Tom Tromey
2025-04-02 23:45 ` [PATCH v2 04/28] Ada import functions not in index Tom Tromey
2025-04-02 23:45 ` [PATCH v2 05/28] Fix index's handling of DW_TAG_imported_declaration Tom Tromey
2025-04-02 23:45 ` [PATCH v2 06/28] Put all CTF symbols in global scope Tom Tromey
2025-04-02 23:45 ` [PATCH v2 07/28] Restore "ingestion" of .debug_str when writing .debug_names Tom Tromey
2025-04-02 23:45 ` [PATCH v2 08/28] Entries from anon-struct.exp not in cooked index Tom Tromey
2025-04-02 23:45 ` [PATCH v2 09/28] Remove dwarf2_per_cu_data::mark Tom Tromey
2025-04-21 3:09 ` Simon Marchi
2025-04-21 15:38 ` Tom Tromey
2025-04-23 4:12 ` Simon Marchi
2025-04-02 23:45 ` [PATCH v2 10/28] Have expand_symtabs_matching work for already-expanded CUs Tom Tromey
2025-04-23 15:53 ` Simon Marchi
2025-04-23 20:39 ` Tom Tromey
2025-04-23 20:57 ` Tom Tromey
2025-04-02 23:45 ` [PATCH v2 11/28] Rewrite the .gdb_index reader Tom Tromey
2025-04-23 17:22 ` Simon Marchi
2025-04-23 20:50 ` Tom Tromey
2025-04-24 14:37 ` Pedro Alves
2025-04-02 23:45 ` [PATCH v2 12/28] Convert default_collect_symbol_completion_matches_break_on Tom Tromey
2025-04-02 23:45 ` [PATCH v2 13/28] Convert gdbpy_lookup_static_symbols Tom Tromey
2025-04-02 23:45 ` [PATCH v2 14/28] Convert ada_add_global_exceptions Tom Tromey
2025-04-02 23:45 ` [PATCH v2 15/28] Convert ada_language_defn::collect_symbol_completion_matches Tom Tromey
2025-04-02 23:45 ` [PATCH v2 16/28] Convert ada-lang.c:map_matching_symbols Tom Tromey
2025-04-02 23:45 ` [PATCH v2 17/28] Remove expand_symtabs_matching Tom Tromey
2025-04-02 23:45 ` [PATCH v2 18/28] Simplify basic_lookup_transparent_type Tom Tromey
2025-04-02 23:45 ` [PATCH v2 19/28] Remove objfile::expand_symtabs_for_function Tom Tromey
2025-04-02 23:45 ` [PATCH v2 20/28] Convert linespec.c:iterate_over_all_matching_symtabs Tom Tromey
2025-04-02 23:45 ` [PATCH v2 21/28] Simplify block_lookup_symbol_primary Tom Tromey
2025-04-02 23:45 ` [PATCH v2 22/28] Pass lookup_name_info to block_lookup_symbol_primary Tom Tromey
2025-04-02 23:45 ` [PATCH v2 23/28] Simplify block_lookup_symbol Tom Tromey
2025-04-02 23:45 ` [PATCH v2 24/28] Add best_symbol_tracker Tom Tromey
2025-04-02 23:45 ` [PATCH v2 25/28] Convert lookup_symbol_via_quick_fns Tom Tromey
2025-04-02 23:45 ` [PATCH v2 26/28] Convert lookup_symbol_in_objfile Tom Tromey
2025-04-02 23:45 ` [PATCH v2 27/28] Make dw_expand_symtabs_matching_file_matcher static Tom Tromey
2025-04-23 20:00 ` Simon Marchi
2025-04-23 20:09 ` Tom Tromey
2025-04-23 20:44 ` Tom Tromey
2025-04-02 23:45 ` [PATCH v2 28/28] Remove enter_symbol_lookup Tom Tromey
2025-04-23 20:09 ` [PATCH v2 00/28] Search symbols via quick API Simon Marchi
2025-04-24 21:09 ` Tom Tromey
2025-04-28 14:07 ` Guinevere Larsen [this message]
2025-04-28 22:06 ` Tom Tromey
2025-04-29 19:31 ` Guinevere Larsen
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=f68701da-2a73-47e9-afe1-535b9512e345@redhat.com \
--to=guinevere@redhat.com \
--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