From: Tom de Vries <tdevries@suse.de>
To: Tom Tromey <tom@tromey.com>
Cc: gdb-patches@sourceware.org
Subject: Re: [PATCH v5 2/3] [gdb/exp] Fix ignoring of incorrect namespace prefix
Date: Tue, 12 May 2026 12:15:22 +0200 [thread overview]
Message-ID: <497953ba-25a2-494e-a207-e01f54af8882@suse.de> (raw)
In-Reply-To: <871pfuhq31.fsf@tromey.com>
On 5/1/26 9:44 PM, Tom Tromey wrote:
>>>>>> "Tom" == Tom de Vries <tdevries@suse.de> writes:
>
> Tom> + const char *current_scope = (block->function_block () != nullptr
> Tom> + ? block->scope ()
> Tom> + : nullptr /* Don't know. */);
>
> Calling block::scope would yield "" even for the static block case.
> So I was wondering why not use that rather than check function_block?
> But like I said elsewhere, I don't really follow this function that well.
AFAIU, you're proposing the following:
...
if (len == 0)
{
const char *current_scope = block->scope ();
directive_match = streq (scope, current_scope);
}
...
That runs into the following regressions:
...
FAIL: gdb.cp/namespace.exp: print X
FAIL: gdb.cp/namespace.exp: print 'G::Xg'
FAIL: gdb.cp/namespace.exp: print G::Xg
FAIL: gdb.cp/namespace.exp: print G::XgX
...
The first can be reproduced like this:
...
$ gdb -q -batch outputs/gdb.cp/namespace/namespace \
-ex "b marker2" -ex run \
-ex "print X"
...
No symbol "X" in current context.
...
The relevant bit of test-case source is:
...
namespace
{
int X = 9;
}
namespace C
{
namespace D
{
void marker2 (void)
{
...
}
}
}
...
So we're in cp_lookup_symbol_via_imports, with:
- scope == "C::D"
- name == "X",
- block == static block
and when looking at (AFAIU) implicit import:
...
(gdb) p *current
$3 = {import_src = 0x348dac0 "(anonymous namespace)",
import_dest = 0x1b477a0 "", alias = 0x0,
declaration = 0x0, next = 0x0, decl_line = 0,
searched = 0, excludes = {0x0}}
...
we're trying to figure out directive_match.
In this case directive_match needs to be true for the test to pass, but
we have scope == "C::D" and current_scope == "", so streq (scope,
current_scope) == false.
So I've left this patch as is in a v6.
Thanks,
- Tom
next prev parent reply other threads:[~2026-05-12 10:16 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-04-19 8:12 [PATCH v5 0/3] [gdb/exp] Fix some namespace issues Tom de Vries
2026-04-19 8:12 ` [PATCH v5 1/3] [gdb] Break up complex assignment in cp_lookup_symbol_via_imports Tom de Vries
2026-04-19 8:12 ` [PATCH v5 2/3] [gdb/exp] Fix ignoring of incorrect namespace prefix Tom de Vries
2026-05-01 19:44 ` Tom Tromey
2026-05-12 10:15 ` Tom de Vries [this message]
2026-05-12 10:24 ` Tom de Vries
2026-04-19 8:12 ` [PATCH v5 3/3] [gdb/exp] Handle recursive namespace import Tom de Vries
2026-05-01 19:37 ` Tom Tromey
2026-05-12 10:22 ` Tom de Vries
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=497953ba-25a2-494e-a207-e01f54af8882@suse.de \
--to=tdevries@suse.de \
--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