* [PATCH v5 1/3] [gdb] Break up complex assignment in cp_lookup_symbol_via_imports
2026-04-19 8:12 [PATCH v5 0/3] [gdb/exp] Fix some namespace issues Tom de Vries
@ 2026-04-19 8:12 ` Tom de Vries
2026-04-19 8:12 ` [PATCH v5 2/3] [gdb/exp] Fix ignoring of incorrect namespace prefix Tom de Vries
2026-04-19 8:12 ` [PATCH v5 3/3] [gdb/exp] Handle recursive namespace import Tom de Vries
2 siblings, 0 replies; 9+ messages in thread
From: Tom de Vries @ 2026-04-19 8:12 UTC (permalink / raw)
To: gdb-patches
In cp_lookup_symbol_via_imports, we have a complex assignment:
...
directive_match = (search_parents
? (startswith (scope, current->import_dest)
&& (len == 0
|| scope[len] == ':'
|| scope[len] == '\0'))
: streq (scope, current->import_dest));
...
Writing it like this makes it:
- harder to comment on parts of the expression, and also
- harder to understand and modify it.
Also, len == 0 makes the startswith redundant, so that part of the expression
can be hoisted. Doing so makes it clear that scope is not compared against in
all cases.
Fix this by breaking this up into three separate assignments:
...
if (search_parents)
{
if (len == 0)
directive_match = true;
else
directive_match = (startswith (scope, current->import_dest)
&& (scope[len] == ':'
|| scope[len] == '\0'));
}
else
directive_match = streq (scope, current->import_dest);
...
Approved-By: Tom Tromey <tom@tromey.com>
---
gdb/cp-namespace.c | 21 ++++++++++++++-------
1 file changed, 14 insertions(+), 7 deletions(-)
diff --git a/gdb/cp-namespace.c b/gdb/cp-namespace.c
index c8cd5c245aa..1903287770b 100644
--- a/gdb/cp-namespace.c
+++ b/gdb/cp-namespace.c
@@ -394,7 +394,6 @@ cp_lookup_symbol_via_imports (const char *scope,
{
struct block_symbol sym = {};
int len;
- int directive_match;
/* All the symbols we found will be kept in this relational map between
the mangled name and the block_symbol found. We do this so that GDB
@@ -425,13 +424,21 @@ cp_lookup_symbol_via_imports (const char *scope,
do not use this directive. */
if (!current->valid_line (boundary_sal.line))
continue;
+
len = strlen (current->import_dest);
- directive_match = (search_parents
- ? (startswith (scope, current->import_dest)
- && (len == 0
- || scope[len] == ':'
- || scope[len] == '\0'))
- : streq (scope, current->import_dest));
+
+ bool directive_match;
+ if (search_parents)
+ {
+ if (len == 0)
+ directive_match = true;
+ else
+ directive_match = (startswith (scope, current->import_dest)
+ && (scope[len] == ':'
+ || scope[len] == '\0'));
+ }
+ else
+ directive_match = streq (scope, current->import_dest);
/* If the import destination is the current scope or one of its
ancestors then it is applicable. */
--
2.51.0
^ permalink raw reply [flat|nested] 9+ messages in thread* [PATCH v5 2/3] [gdb/exp] Fix ignoring of incorrect namespace prefix
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 ` Tom de Vries
2026-05-01 19:44 ` Tom Tromey
2026-04-19 8:12 ` [PATCH v5 3/3] [gdb/exp] Handle recursive namespace import Tom de Vries
2 siblings, 1 reply; 9+ messages in thread
From: Tom de Vries @ 2026-04-19 8:12 UTC (permalink / raw)
To: gdb-patches
Consider test.c, compiled to a.out using "g++ -g test.c":
...
1 namespace mod_a { int xxx = 10; }
2 namespace mod_b { using namespace mod_a;
3 int yyy = 20; }
4 int main (void) {
5 using namespace mod_b;
6 void (xxx + yyy);
7 return 0;
8 }
...
When trying to print the value of non-existent variable mod_a::yyy, we get:
...
$ gdb -q -batch a.out -ex start -ex "print mod_a::yyy"
...
Temporary breakpoint 1, main () at test.c:7
7 return 0;
$1 = 20
...
The problem is in cp_lookup_symbol_via_imports, where we decide that the
"using namespace mod_b" from main is applicable in scope mod_a.
Fix this by being more strict in the calculation of directive_match:
...
if (len == 0)
- directive_match = true;
+ {
+ const char *current_scope = (block->function_block () != nullptr
+ ? block->scope ()
+ : nullptr /* Don't know. */);
+ directive_match = (current_scope != nullptr
+ ? streq (scope, current_scope)
+ : true /* Assume there's a match. */);
+ }
...
As is clear from the code, in case we don't know the current scope, we assume
there's a match. This may be harmless, or this may describe a cornercase we
haven't run into yet. If so, it's a pre-existing issue.
The new test-case contains regression tests for:
- PR34051, and
- PR34034 for which it contains a kfail.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=34051
---
gdb/cp-namespace.c | 9 +++-
gdb/testsuite/gdb.cp/nsusing-2.cc | 62 ++++++++++++++++++++++++
gdb/testsuite/gdb.cp/nsusing-2.exp | 75 ++++++++++++++++++++++++++++++
3 files changed, 145 insertions(+), 1 deletion(-)
create mode 100644 gdb/testsuite/gdb.cp/nsusing-2.cc
create mode 100644 gdb/testsuite/gdb.cp/nsusing-2.exp
diff --git a/gdb/cp-namespace.c b/gdb/cp-namespace.c
index 1903287770b..d7a960127dc 100644
--- a/gdb/cp-namespace.c
+++ b/gdb/cp-namespace.c
@@ -431,7 +431,14 @@ cp_lookup_symbol_via_imports (const char *scope,
if (search_parents)
{
if (len == 0)
- directive_match = true;
+ {
+ const char *current_scope = (block->function_block () != nullptr
+ ? block->scope ()
+ : nullptr /* Don't know. */);
+ directive_match = (current_scope != nullptr
+ ? streq (scope, current_scope)
+ : true /* Assume there's a match. */);
+ }
else
directive_match = (startswith (scope, current->import_dest)
&& (scope[len] == ':'
diff --git a/gdb/testsuite/gdb.cp/nsusing-2.cc b/gdb/testsuite/gdb.cp/nsusing-2.cc
new file mode 100644
index 00000000000..226bda3e101
--- /dev/null
+++ b/gdb/testsuite/gdb.cp/nsusing-2.cc
@@ -0,0 +1,62 @@
+/* This testcase is part of GDB, the GNU debugger.
+
+ Copyright 2026 Free Software Foundation, Inc.
+
+ This program is free software; you can redistribute it and/or modify
+ it under the terms of the GNU General Public License as published by
+ the Free Software Foundation; either version 3 of the License, or
+ (at your option) any later version.
+
+ This program is distributed in the hope that it will be useful,
+ but WITHOUT ANY WARRANTY; without even the implied warranty of
+ MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ GNU General Public License for more details.
+
+ You should have received a copy of the GNU General Public License
+ along with this program. If not, see <http://www.gnu.org/licenses/>. */
+
+/* C++ variant of the Fortran example from PR34034. */
+
+namespace mod_a {
+ int xxx = 10;
+}
+
+namespace mod_b {
+ using namespace mod_a;
+ int yyy = 20;
+}
+
+static void foo () {}
+
+int
+main (void)
+{
+ foo (); /* main-entry. */
+
+ { /* Variant 1: using block is stop block, using block is not function block. */
+ using namespace mod_b;
+ void (xxx + yyy);
+ foo (); /* main-1. */
+ }
+
+ { /* Variant 2: using block is super block of stop block, using block is not function block. */
+ using namespace mod_b;
+ {
+ void (xxx + yyy);
+ foo (); /* main-2. */
+ }
+ }
+
+ using namespace mod_b;
+
+ { /* Variant 3: using block is super block of stop block, using block is function block. */
+ void (xxx + yyy);
+ foo (); /* main-3. */
+ }
+
+ /* Variant 4: using block is stop block, using block is function block. */
+ void (xxx + yyy);
+ foo (); /* main-4. */
+
+ return 0;
+}
diff --git a/gdb/testsuite/gdb.cp/nsusing-2.exp b/gdb/testsuite/gdb.cp/nsusing-2.exp
new file mode 100644
index 00000000000..65e685d0d32
--- /dev/null
+++ b/gdb/testsuite/gdb.cp/nsusing-2.exp
@@ -0,0 +1,75 @@
+# Copyright 2026 Free Software Foundation, Inc.
+
+# This program is free software; you can redistribute it and/or modify
+# it under the terms of the GNU General Public License as published by
+# the Free Software Foundation; either version 3 of the License, or
+# (at your option) any later version.
+#
+# This program is distributed in the hope that it will be useful,
+# but WITHOUT ANY WARRANTY; without even the implied warranty of
+# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+# GNU General Public License for more details.
+#
+# You should have received a copy of the GNU General Public License
+# along with this program. If not, see <http://www.gnu.org/licenses/>.
+
+# Test recursive "using namespace". Regression test for PR34034 and PR34051.
+
+standard_testfile .cc
+
+if {[prepare_for_testing "failed to prepare" $testfile $srcfile \
+ {debug c++}]} {
+ return
+}
+
+with_test_prefix pre-main {
+ gdb_test "print mod_a::xxx" " = 10"
+ gdb_test "print mod_b::yyy" " = 20"
+
+ # Namespace mod_b is using namespace mod_a, so mod_a::xxx is available as
+ # mod_b::xxx. This is not available here though, but later, at
+ # start-of-main. I wonder if this should also be available here.
+ gdb_test "print mod_b::xxx" \
+ [string_to_regexp {No symbol "xxx" in namespace "mod_b".}]
+}
+
+set line_main_entry [gdb_get_line_number main-entry]
+if {![runto $srcfile:$line_main_entry]} {
+ return
+}
+
+# Start of main. Function main is not yet using namespace mod_b.
+with_test_prefix start-of-main {
+ # Namespace mod_b is using namespace mod_a, so mod_a::xxx is available as
+ # mod_b::xxx. See also the note at the identical command in pre-main.
+ gdb_test "print mod_b::xxx" " = 10"
+
+ # Same command as in end-of-main, but not a regression test for PR34034.
+ gdb_test "print xxx" \
+ [string_to_regexp {No symbol "xxx" in current context.}]
+
+ # Same test as in end-of-main, but not a regression test for PR34051.
+ gdb_test "print mod_a::yyy" \
+ [string_to_regexp {No symbol "yyy" in namespace "mod_a".}]
+}
+
+# After start of main. Function main is using namespace mod_b. Check 4 variants.
+foreach_with_prefix n {1 2 3 4} {
+ set line_main_n [gdb_get_line_number "main-$n"]
+ gdb_test "next" \
+ [subst_vars {$line_main_n\t[^\r\n]+}]
+
+ # Function main is using namespace mod_b, so mod_b::yyy is available as
+ # yyy.
+ gdb_test "print yyy" " = 20"
+
+ # Function main is using namespace mod_b, and namespace mod_b is using
+ # namespace mod_a, so mod_a::xxx is available as xxx. Regression test for
+ # PR34034.
+ setup_kfail exp/34034 *-*-*
+ gdb_test "print xxx" " = 10"
+
+ # This used to print " $<n> = 20". Regression test for PR34051.
+ gdb_test "print mod_a::yyy" \
+ [string_to_regexp {No symbol "yyy" in namespace "mod_a".}]
+}
--
2.51.0
^ permalink raw reply [flat|nested] 9+ messages in thread* Re: [PATCH v5 2/3] [gdb/exp] Fix ignoring of incorrect namespace prefix
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
0 siblings, 1 reply; 9+ messages in thread
From: Tom Tromey @ 2026-05-01 19:44 UTC (permalink / raw)
To: Tom de Vries; +Cc: gdb-patches
>>>>> "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.
thanks,
Tom
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [PATCH v5 2/3] [gdb/exp] Fix ignoring of incorrect namespace prefix
2026-05-01 19:44 ` Tom Tromey
@ 2026-05-12 10:15 ` Tom de Vries
2026-05-12 10:24 ` Tom de Vries
0 siblings, 1 reply; 9+ messages in thread
From: Tom de Vries @ 2026-05-12 10:15 UTC (permalink / raw)
To: Tom Tromey; +Cc: gdb-patches
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
^ permalink raw reply [flat|nested] 9+ messages in thread
* [PATCH v5 3/3] [gdb/exp] Handle recursive namespace import
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-04-19 8:12 ` Tom de Vries
2026-05-01 19:37 ` Tom Tromey
2 siblings, 1 reply; 9+ messages in thread
From: Tom de Vries @ 2026-04-19 8:12 UTC (permalink / raw)
To: gdb-patches
Consider test.c, compiled to a.out using "g++ -g test.c":
...
1 namespace mod_a { int xxx = 10; }
2 namespace mod_b { using namespace mod_a;
3 int yyy = 20; }
4 int main (void) {
5 using namespace mod_b;
6 void (xxx + yyy);
7 return 0;
8 }
...
When trying to print the value of variable xxx we get:
...
$ gdb -q -batch a.out -ex start -ex "print xxx"
...
Temporary breakpoint 1, main () at test.c:7
7 return 0;
No symbol "xxx" in current context.
...
The symbol xxx is defined in namespace mod_a, so it's available as:
...
(gdb) p mod_a::xxx
$1 = 10
...
and namespace mod_b uses namespace mod_a, so it's available as:
...
(gdb) p mod_b::xxx
$2 = 10
...
Then main uses namespace mod_b so xxx should also be available in main, but
it's not.
The problem happens here in cp_lookup_symbol_via_imports:
...
Thread 1 "gdb" hit Breakpoint 1, cp_lookup_symbol_via_imports (scope=0x5f43d0 "",
name=0xfffffffface0 "xxx", block=0x2fba5a0, domain=..., search_scope_first=0,
declaration_only=0, search_parents=1, found_symbols=...)
at /home/vries/gdb/src/gdb/cp-namespace.c:505
505 cp_lookup_symbol_via_imports (current->import_src, name,
...
We're about to follow the "using namespace mod_b" statement:
...
(gdb) p *current
$1 = {import_src = 0x2ed2140 "mod_b", import_dest = 0x66e910 "", alias = 0x0,
declaration = 0x0, next = 0x0, decl_line = 5, searched = 1,
excludes = {0x0}}
...
But it does so using the current block, which is the function block for main:
...
(gdb) p block->function ().m_name
$7 = 0x2f8bc20 "main()"
...
and the block containing the "using namespace mod_a" statement is the static
block.
Fix this by additionally iterating over the super blocks instead of only using
the current block.
Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=34034
---
gdb/cp-namespace.c | 8 +++++---
gdb/testsuite/gdb.cp/nsusing-2.exp | 1 -
2 files changed, 5 insertions(+), 4 deletions(-)
diff --git a/gdb/cp-namespace.c b/gdb/cp-namespace.c
index d7a960127dc..a0d86fd26f0 100644
--- a/gdb/cp-namespace.c
+++ b/gdb/cp-namespace.c
@@ -502,9 +502,11 @@ cp_lookup_symbol_via_imports (const char *scope,
/* If this import statement creates no alias, pass
current->inner as NAMESPACE to direct the search
towards the imported namespace. */
- cp_lookup_symbol_via_imports (current->import_src, name,
- block, domain, 1, 0, 0,
- found_symbols);
+ for (const struct block *b = block; b != nullptr;
+ b = b->superblock ())
+ cp_lookup_symbol_via_imports (current->import_src, name,
+ b, domain, 1, 0, 0,
+ found_symbols);
}
}
diff --git a/gdb/testsuite/gdb.cp/nsusing-2.exp b/gdb/testsuite/gdb.cp/nsusing-2.exp
index 65e685d0d32..5a2eac5ce67 100644
--- a/gdb/testsuite/gdb.cp/nsusing-2.exp
+++ b/gdb/testsuite/gdb.cp/nsusing-2.exp
@@ -66,7 +66,6 @@ foreach_with_prefix n {1 2 3 4} {
# Function main is using namespace mod_b, and namespace mod_b is using
# namespace mod_a, so mod_a::xxx is available as xxx. Regression test for
# PR34034.
- setup_kfail exp/34034 *-*-*
gdb_test "print xxx" " = 10"
# This used to print " $<n> = 20". Regression test for PR34051.
--
2.51.0
^ permalink raw reply [flat|nested] 9+ messages in thread* Re: [PATCH v5 3/3] [gdb/exp] Handle recursive namespace import
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
0 siblings, 1 reply; 9+ messages in thread
From: Tom Tromey @ 2026-05-01 19:37 UTC (permalink / raw)
To: Tom de Vries; +Cc: gdb-patches
>>>>> "Tom" == Tom de Vries <tdevries@suse.de> writes:
Tom> Fix this by additionally iterating over the super blocks instead of only using
Tom> the current block.
FWIW I haven't really commented much on the core part of this series
because I find this code pretty confusing and I'm not really sure I
understand it well enough to do a good job reviewing it.
Tom> + for (const struct block *b = block; b != nullptr;
Tom> + b = b->superblock ())
Tom> + cp_lookup_symbol_via_imports (current->import_src, name,
Tom> + b, domain, 1, 0, 0,
In this spot, suppose 'block' is from an inlined function. Then when
iterating, I think we'll end up seeing blocks from the enclosing
function (the one that was inlined-into). However, that could yield the
wrong result, because the inlined and inlined-into functions could come
from completely different namespace contexts with different 'using'
directives.
Tom
^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [PATCH v5 3/3] [gdb/exp] Handle recursive namespace import
2026-05-01 19:37 ` Tom Tromey
@ 2026-05-12 10:22 ` Tom de Vries
0 siblings, 0 replies; 9+ messages in thread
From: Tom de Vries @ 2026-05-12 10:22 UTC (permalink / raw)
To: Tom Tromey; +Cc: gdb-patches
On 5/1/26 9:37 PM, Tom Tromey wrote:
>>>>>> "Tom" == Tom de Vries <tdevries@suse.de> writes:
>
> Tom> Fix this by additionally iterating over the super blocks instead of only using
> Tom> the current block.
>
> FWIW I haven't really commented much on the core part of this series
> because I find this code pretty confusing and I'm not really sure I
> understand it well enough to do a good job reviewing it.
>
> Tom> + for (const struct block *b = block; b != nullptr;
> Tom> + b = b->superblock ())
> Tom> + cp_lookup_symbol_via_imports (current->import_src, name,
> Tom> + b, domain, 1, 0, 0,
>
> In this spot, suppose 'block' is from an inlined function. Then when
> iterating, I think we'll end up seeing blocks from the enclosing
> function (the one that was inlined-into). However, that could yield the
> wrong result, because the inlined and inlined-into functions could come
> from completely different namespace contexts with different 'using'
> directives.
Thanks for pointing this out, fixed in a v6 (
https://sourceware.org/pipermail/gdb-patches/2026-May/227330.html ).
Thanks,
- Tom
^ permalink raw reply [flat|nested] 9+ messages in thread