From: Tom Tromey <tromey@adacore.com>
To: Markus Metzger via Gdb-patches <gdb-patches@sourceware.org>
Subject: Re: [PATCH v5 10/15] gdb, ada: update ada_add_all_symbols
Date: Mon, 18 Jul 2022 10:56:50 -0600 [thread overview]
Message-ID: <87fsiyl5pp.fsf@tromey.com> (raw)
In-Reply-To: <20220602132514.957983-11-markus.t.metzger@intel.com> (Markus Metzger via Gdb-patches's message of "Thu, 2 Jun 2022 15:25:09 +0200")
>>>>> "Markus" == Markus Metzger via Gdb-patches <gdb-patches@sourceware.org> writes:
Markus> Iterate over objfile in search order using the objfile of the context
Markus> block as current_objfile so the iteration can stay inside the block's
Markus> linker namespace.
I think this function is used by linespec, meaning it's called when
setting a breakpoint. So in this case, limiting the results to the
current namespace seems possibly incorrect to me.
Was there a particular reason for this limitation?
I tend to doubt that Ada users are using dlmopen. So maybe either way
is ok. However, erring on the side of too many results seems possibly
better, just in case someone does start using this combination of
features.
Tom
next prev parent reply other threads:[~2022-07-18 16:56 UTC|newest]
Thread overview: 52+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-06-02 13:24 [PATCH v5 00/15] basic linker namespace support Markus Metzger
2022-06-02 13:25 ` [PATCH v5 01/15] gdb, testsuite: extend gdb_test_multiple checks Markus Metzger
2022-06-13 1:28 ` Kevin Buettner
2022-06-02 13:25 ` [PATCH v5 02/15] gdb, solib-svr4: remove locate_base() Markus Metzger
2022-06-02 23:04 ` Kevin Buettner
2022-06-02 13:25 ` [PATCH v5 03/15] gdb, gdbserver: support dlmopen() Markus Metzger
2022-06-19 4:02 ` Kevin Buettner
2022-06-27 12:55 ` Metzger, Markus T
2022-06-30 22:35 ` Kevin Buettner
2022-06-02 13:25 ` [PATCH v5 04/15] gdbserver: move main_lm handling into caller Markus Metzger
2022-06-19 4:22 ` Kevin Buettner
2022-06-02 13:25 ` [PATCH v5 05/15] gdb, gdbserver: extend RSP to support namespaces Markus Metzger
2022-06-02 16:09 ` Eli Zaretskii
2022-06-19 4:32 ` Kevin Buettner
2022-06-02 13:25 ` [PATCH v5 06/15] gdb, compile: unlink objfile stored in module Markus Metzger
2022-06-23 17:20 ` Kevin Buettner
2022-06-02 13:25 ` [PATCH v5 07/15] gdb, python: use gdbarch_iterate_over_objfiles_in_search_order Markus Metzger
2022-06-24 17:18 ` Kevin Buettner
2022-06-02 13:25 ` [PATCH v5 08/15] gdb, ada: collect standard exceptions in all objfiles Markus Metzger
2022-06-24 17:26 ` Kevin Buettner
2022-07-18 16:49 ` Tom Tromey
2022-07-18 5:35 ` Metzger, Markus T
2022-09-14 8:19 ` Metzger, Markus T
2022-09-14 8:37 ` Joel Brobecker
2022-09-14 8:45 ` Metzger, Markus T
2022-06-02 13:25 ` [PATCH v5 09/15] gdb, ada: update ada_lookup_simple_minsym Markus Metzger
2022-06-24 23:42 ` Kevin Buettner
2022-07-18 17:02 ` Tom Tromey
2022-07-19 7:14 ` Metzger, Markus T
2022-09-14 8:19 ` Metzger, Markus T
2022-09-21 16:11 ` Tom Tromey
2022-06-02 13:25 ` [PATCH v5 10/15] gdb, ada: update ada_add_all_symbols Markus Metzger
2022-06-24 23:53 ` Kevin Buettner
2022-07-18 5:36 ` Metzger, Markus T
2022-07-18 16:56 ` Tom Tromey [this message]
2022-07-19 7:13 ` Metzger, Markus T
2022-07-19 12:23 ` Tom Tromey
2022-07-19 13:49 ` Metzger, Markus T
2022-06-02 13:25 ` [PATCH v5 11/15] gdb, cp: update add_symbol_overload_list_qualified Markus Metzger
2022-06-24 23:59 ` Kevin Buettner
2022-06-02 13:25 ` [PATCH v5 12/15] gdb, hppa: remove unused hppa_lookup_stub_minimal_symbol Markus Metzger
2022-06-25 0:01 ` Kevin Buettner
2022-06-02 13:25 ` [PATCH v5 13/15] gdb, symtab: inline find_quick_global_symbol_language Markus Metzger
2022-06-25 0:16 ` Kevin Buettner
2022-06-02 13:25 ` [PATCH v5 14/15] gdb: update gnu ifunc resolve Markus Metzger
2022-06-25 0:34 ` Kevin Buettner
2022-06-02 13:25 ` [PATCH v5 15/15] gdb, solib-svr4: support namespaces in DSO iteration Markus Metzger
2022-06-25 0:42 ` Kevin Buettner
2022-07-15 10:30 ` [PATCH v5 00/15] basic linker namespace support Metzger, Markus T
2022-07-16 0:04 ` Kevin Buettner
2022-07-18 5:33 ` Metzger, Markus T
2022-10-05 11:16 ` Metzger, Markus T
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=87fsiyl5pp.fsf@tromey.com \
--to=tromey@adacore.com \
--cc=gdb-patches@sourceware.org \
/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).