[v7,5/5] Fixed gdb: prefer symtabs for the current linker namespace
Commit Message
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.
---
This is a resend of the patch 5/5 sent on monday. That's because the
original patch failed to consider the user searching for a symtab before
starting the inferior, when solib_ops () is unset, which causes GDB to
crash.
---
gdb/symtab.c | 6 ++++++
gdb/testsuite/gdb.base/dlmopen-ns-ids-main.c | 3 +++
gdb/testsuite/gdb.base/dlmopen-ns-ids.exp | 9 +++++++++
3 files changed, 18 insertions(+)
base-commit: 6646680f5aa9745b5188afa5b66f6909b0f503d7
@@ -655,6 +655,12 @@ find_symtab (program_space *pspace, const char *name,
}
else
{
+ if (pspace->solib_ops ()!= nullptr
+ && pspace->solib_ops ()->supports_namespaces ()
+ && pspace->solib_ops ()->num_active_namespaces () > 1)
+ objfiles_to_search
+ = get_objfiles_in_linker_namespace (get_current_linker_namespace (),
+ pspace);
for (objfile &objf : pspace->objfiles ())
objfiles_to_search.push_back (&objf);
}
@@ -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 */
@@ -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