Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Guinevere Larsen <guinevere@redhat.com>
To: gdb-patches@sourceware.org
Subject: Re: [PATCH v7 5/5] gdb: prefer symtabs for the current linker namespace
Date: Wed, 3 Jun 2026 15:26:24 -0300	[thread overview]
Message-ID: <dade84aa-b221-4f9c-be5e-83bf5f71fe15@redhat.com> (raw)
In-Reply-To: <20260601192251.60958-6-guinevere@redhat.com>

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


-- 
Cheers,
Guinevere Larsen
It/she


  reply	other threads:[~2026-06-03 18:27 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-06-01 19:22 [PATCH v7 0/5] Introduce syntax for linker-namespace specific symbols Guinevere Larsen
2026-06-01 19:22 ` [PATCH v7 1/5] gdb: Create helper function for the current namespace Guinevere Larsen
2026-06-01 19:22 ` [PATCH v7 2/5] gdb: make lookup_minimal_symbol_linkage work with linker namespaces Guinevere Larsen
2026-06-01 19:22 ` [PATCH v7 3/5] gdb: Make the parser recognize the [[N]] syntax for variables Guinevere Larsen
2026-06-01 19:22 ` [PATCH v7 4/5] gdb: extend the [[N]]::foo syntax for files Guinevere Larsen
2026-06-01 19:22 ` [PATCH v7 5/5] gdb: prefer symtabs for the current linker namespace Guinevere Larsen
2026-06-03 18:26   ` Guinevere Larsen [this message]
2026-06-03 19:16 ` [PATCH v7 5/5] Fixed " Guinevere Larsen
2026-06-22 20:35 ` [PING][PATCH v7 0/5] Introduce syntax for linker-namespace specific symbols 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=dade84aa-b221-4f9c-be5e-83bf5f71fe15@redhat.com \
    --to=guinevere@redhat.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