diff options
author | Markus Metzger <markus.t.metzger@intel.com> | 2022-03-28 11:20:10 +0200 |
---|---|---|
committer | Markus Metzger <markus.t.metzger@intel.com> | 2022-10-18 14:16:11 +0200 |
commit | aebb370bae3f511df8afb68a01a79c54e2066650 (patch) | |
tree | 8e9e25276a2768eb2352ea514377f08c662c7c4f /gdb/solib-svr4.c | |
parent | 1dc9084f5e95fd9a1f2f0e9baf9c6e52c5a5ee29 (diff) | |
download | gdb-aebb370bae3f511df8afb68a01a79c54e2066650.zip gdb-aebb370bae3f511df8afb68a01a79c54e2066650.tar.gz gdb-aebb370bae3f511df8afb68a01a79c54e2066650.tar.bz2 |
gdb, solib-svr4: support namespaces in DSO iteration
When looking up names, GDB needs to stay within one linker namespace to
find the correct instance in case the same name is provided in more than
one namespace.
Modify svr4_iterate_over_objfiles_in_search_order() to stay within the
namespace of the current_objfile argument. If no current_objfile is
provided (i.e. it is nullptr), iterate over objfiles in the initial
namespace.
For objfiles that do not have a corresponding so_list to provide the
namespace, assume that the objfile was loaded into the initial namespace.
This would cover the main executable objfile (which is indeed loaded into
the initial namespace) as well as manually added symbol files.
Expected fails:
- gdb.base/non-lazy-array-index.exp: the expression parser may lookup
global symbols, which may result in xfers to read auxv for determining
the debug base as part of svr4_iterate_over_objfiles_in_search_order().
- gdb.server/non-lazy-array-index.exp: symbol lookup may access the
target to read AUXV in order to determine the debug base for SVR4
linker namespaces.
Known issues:
- get_symbol_address() and get_msymbol_address() search objfiles for a
'better' match. This was introduced by
4b610737f02 Handle copy relocations
to handle copy relocations but it now causes a wrong address to be
read after symbol lookup actually cound the correct symbol. This can
be seen, for example, with gdb.base/dlmopen.exp when compiled with
clang.
- gnu ifuncs are only looked up in the initial namespace.
- lookup_minimal_symbol() and lookup_minimal_symbol_text() directly
iterate over objfiles and are not aware of linker namespaces.
Diffstat (limited to 'gdb/solib-svr4.c')
-rw-r--r-- | gdb/solib-svr4.c | 78 |
1 files changed, 76 insertions, 2 deletions
diff --git a/gdb/solib-svr4.c b/gdb/solib-svr4.c index 295e9b8..6acaf87 100644 --- a/gdb/solib-svr4.c +++ b/gdb/solib-svr4.c @@ -3313,9 +3313,60 @@ svr4_lp64_fetch_link_map_offsets (void) } +/* Return the DSO matching OBJFILE or nullptr if none can be found. */ + +static so_list * +find_solib_for_objfile (struct objfile *objfile) +{ + if (objfile == nullptr) + return nullptr; + + /* If OBJFILE is a separate debug object file, look for the original + object file. */ + if (objfile->separate_debug_objfile_backlink != nullptr) + objfile = objfile->separate_debug_objfile_backlink; + + for (so_list *so : current_program_space->solibs ()) + if (so->objfile == objfile) + return so; + + return nullptr; +} + +/* Return the address of the r_debug object for the namespace containing + SOLIB or zero if it cannot be found. This may happen when symbol files + are added manually, for example, or with the main executable. + + Current callers treat zero as initial namespace so they are doing the + right thing for the main executable. */ + +static CORE_ADDR +find_debug_base_for_solib (so_list *solib) +{ + if (solib == nullptr) + return 0; + + svr4_info *info = get_svr4_info (current_program_space); + gdb_assert (info != nullptr); + for (const std::pair<CORE_ADDR, so_list *> tuple + : info->solib_lists) + { + CORE_ADDR debug_base = tuple.first; + so_list *solist = tuple.second; + + for (; solist != nullptr; solist = solist->next) + if (svr4_same (solib, solist)) + return debug_base; + } + + return 0; +} + /* Search order for ELF DSOs linked with -Bsymbolic. Those DSOs have a - different rule for symbol lookup. The lookup begins here in the DSO, not in - the main executable. */ + different rule for symbol lookup. The lookup begins here in the DSO, + not in the main executable. When starting from CURRENT_OBJFILE, we + stay in the same namespace as that file. Otherwise, we only consider + the initial namespace. */ static void svr4_iterate_over_objfiles_in_search_order @@ -3344,10 +3395,33 @@ svr4_iterate_over_objfiles_in_search_order } } + /* The linker namespace to iterate identified by the address of its + r_debug object, defaulting to the initial namespace. */ + CORE_ADDR initial = elf_locate_base (); + so_list *curr_solib = find_solib_for_objfile (current_objfile); + CORE_ADDR debug_base = find_debug_base_for_solib (curr_solib); + if (debug_base == 0) + debug_base = initial; + for (objfile *objfile : current_program_space->objfiles ()) { if (checked_current_objfile && objfile == current_objfile) continue; + + /* Try to determine the namespace into which objfile was loaded. + + If we fail, e.g. for manually added symbol files or for the main + executable, we assume that they were added to the initial + namespace. */ + so_list *solib = find_solib_for_objfile (objfile); + CORE_ADDR solib_base = find_debug_base_for_solib (solib); + if (solib_base == 0) + solib_base = initial; + + /* Ignore objfiles that were added to a different namespace. */ + if (solib_base != debug_base) + continue; + if (cb (objfile)) return; } |