[v7,5/5] gdb: prefer symtabs for the current linker namespace

  When a user uses the syntax 'filename'::expression, GDB will search
symtabs in the order they were loaded by the inferior. This can lead to
situations where the following happens:

(gdb) p $_linker_namespace
$1 = 3
(gdb) p [[1]]::gdb_dlmopen_glob = 1
$2 = 1
(gdb) p [[2]]::gdb_dlmopen_glob = 2
$3 = 2
(gdb) p [[3]]::gdb_dlmopen_glob = 3
$4 = 3
(gdb) p gdb_dlmopen_glob == 'dlmopen-ns-ids-lib.c'::gdb_dlmopen_glob
$5 = 0
(gdb) p gdb_dlmopen_glob
$6 = 3
(gdb) p 'dlmopen-ns-ids-lib.c'::gdb_dlmopen_glob
$7 = 1

As a user, I would expect the expressions with and without the filename
returned the exact same variable. As mentioned, because the library was
loaded on namespace 1 first, that symtab is loaded first.

This commit solves that issue by placing a copy of all symtabs in the
current namespace first, and then adding all solibs. This can lead to a
performance loss if the user is in namespace N and the symtab they are
looking for is after all symtabs in namespace N, because all those
symtabs will be searched first. However, I believe this is not a big
concern, as I imagine most of the times that this syntax will be used,
the user will either search for a symtab in the current namespace or the
default one, meaning there is little chance that this will be very
noticeable. This could be avoided by creating a set of the symtabs on
the current namespace, and then when adding all symtabs, not re-adding
ones that were there already, but this seems like too much complexity
for an edge case.
---
 gdb/symtab.c                                 | 4 ++++
 gdb/testsuite/gdb.base/dlmopen-ns-ids-main.c | 3 +++
 gdb/testsuite/gdb.base/dlmopen-ns-ids.exp    | 9 +++++++++
 3 files changed, 16 insertions(+)
  

On 6/1/26 4:22 PM, Guinevere Larsen wrote:
> When a user uses the syntax 'filename'::expression, GDB will search
> symtabs in the order they were loaded by the inferior. This can lead to
> situations where the following happens:
>
> (gdb) p $_linker_namespace
> $1 = 3
> (gdb) p [[1]]::gdb_dlmopen_glob = 1
> $2 = 1
> (gdb) p [[2]]::gdb_dlmopen_glob = 2
> $3 = 2
> (gdb) p [[3]]::gdb_dlmopen_glob = 3
> $4 = 3
> (gdb) p gdb_dlmopen_glob == 'dlmopen-ns-ids-lib.c'::gdb_dlmopen_glob
> $5 = 0
> (gdb) p gdb_dlmopen_glob
> $6 = 3
> (gdb) p 'dlmopen-ns-ids-lib.c'::gdb_dlmopen_glob
> $7 = 1
>
> As a user, I would expect the expressions with and without the filename
> returned the exact same variable. As mentioned, because the library was
> loaded on namespace 1 first, that symtab is loaded first.
>
> This commit solves that issue by placing a copy of all symtabs in the
> current namespace first, and then adding all solibs. This can lead to a
> performance loss if the user is in namespace N and the symtab they are
> looking for is after all symtabs in namespace N, because all those
> symtabs will be searched first. However, I believe this is not a big
> concern, as I imagine most of the times that this syntax will be used,
> the user will either search for a symtab in the current namespace or the
> default one, meaning there is little chance that this will be very
> noticeable. This could be avoided by creating a set of the symtabs on
> the current namespace, and then when adding all symtabs, not re-adding
> ones that were there already, but this seems like too much complexity
> for an edge case.
> ---

Turns out I didn't test this patch thoroughly enough and Linaro CI 
pointed out that this causes several regressions.

I'm trying to figure out how to fix it, but just as a heads up to anyone 
who might be looking at this, I am aware of the failures...

>   gdb/symtab.c                                 | 4 ++++
>   gdb/testsuite/gdb.base/dlmopen-ns-ids-main.c | 3 +++
>   gdb/testsuite/gdb.base/dlmopen-ns-ids.exp    | 9 +++++++++
>   3 files changed, 16 insertions(+)
>
> diff --git a/gdb/symtab.c b/gdb/symtab.c
> index d7317a758b1..b5ef0ddc147 100644
> --- a/gdb/symtab.c
> +++ b/gdb/symtab.c
> @@ -655,6 +655,10 @@ find_symtab (program_space *pspace, const char *name,
>       }
>     else
>       {
> +      if (pspace->solib_ops ()->supports_namespaces ())
> +	objfiles_to_search
> +	  = get_objfiles_in_linker_namespace (get_current_linker_namespace (),
> +					      pspace);
>         for (objfile &objf : pspace->objfiles ())
>   	objfiles_to_search.push_back (&objf);
>       }
> diff --git a/gdb/testsuite/gdb.base/dlmopen-ns-ids-main.c b/gdb/testsuite/gdb.base/dlmopen-ns-ids-main.c
> index 35c5124a65e..012decc25e5 100644
> --- a/gdb/testsuite/gdb.base/dlmopen-ns-ids-main.c
> +++ b/gdb/testsuite/gdb.base/dlmopen-ns-ids-main.c
> @@ -52,6 +52,9 @@ main (void)
>     fun = dlsym (handle[0], "func_with_other_call");
>     fun (0);
>   
> +  fun = dlsym (handle[2], "func_with_other_call");
> +  fun (0);
> +
>     dlclose (handle[0]); /* TAG: first dlclose */
>     dlclose (handle[1]); /* TAG: second dlclose */
>     dlclose (handle[2]); /* TAG: third dlclose */
> diff --git a/gdb/testsuite/gdb.base/dlmopen-ns-ids.exp b/gdb/testsuite/gdb.base/dlmopen-ns-ids.exp
> index 78daed4518e..9c9f97e6887 100644
> --- a/gdb/testsuite/gdb.base/dlmopen-ns-ids.exp
> +++ b/gdb/testsuite/gdb.base/dlmopen-ns-ids.exp
> @@ -370,6 +370,15 @@ proc_with_prefix test_print_namespace_symbol {} {
>       gdb_test "print ${ns2}::'${::srcfile_lib}'::gdb_dlmopen_glob + '${::srcfile}'::global_main_file" \
>   	".* = 1312"
>   
> +    gdb_continue_to_breakpoint "change_global in namespace 2"
> +    # GDB would find symtabs in load order, ignoring the current linker namespace.
> +    # This test ensures that we prefer the symtabs in the namespace in the current
> +    # point of execution instead.
> +    gdb_test "print gdb_dlmopen_glob == '${::srcfile_lib}'::gdb_dlmopen_glob" \
> +	".* = 1" "symtab prioritizes the current namespace"
> +    gdb_test "print &gdb_dlmopen_glob == &'${::srcfile_lib}'::gdb_dlmopen_glob" \
> +	".* = 1" "Double checking with addresses"
> +
>       # Leave to default namespace.
>       gdb_continue_to_breakpoint "TAG: first dlclose"
>       # This global doesn't exist in the default namespace.  Rather than