There are static CORE_ADDR solib_svr4_r_ldsomap (struct svr4_info *info) { struct link_map_offsets *lmo = svr4_fetch_link_map_offsets (); struct type *ptr_type = builtin_type (target_gdbarch ())->builtin_data_ptr; enum bfd_endian byte_order = type_byte_order (ptr_type); ULONGEST version = 0; try { /* Check version, and return zero if `struct r_debug' doesn't have the r_ldsomap member. */ version = read_memory_unsigned_integer (info->debug_base + lmo->r_version_offset, lmo->r_version_size, byte_order); } catch (const gdb_exception_error &ex) { exception_print (gdb_stderr, ex); } if (version < 2 || lmo->r_ldsomap_offset == -1) return 0; return read_memory_typed_address (info->debug_base + lmo->r_ldsomap_offset, ptr_type); } glibc is planning to bump r_version to support multiple namespaces. But there is no r_ldsomap when r_version is bumped to 2.
(In reply to H.J. Lu from comment #0) > glibc is planning to bump r_version to support multiple namespaces. But > there is no r_ldsomap when r_version is bumped to 2. Agreed. The r_ldsomap is only present in Solaris (part of librtld_db), and should never be accessed for Linux. The entire layout of r_debug is OS-specific.
Fixed for GDB 12 by commit c0154a4a21a3aed01ef53877af05cf0109a0b124 Author: H.J. Lu <hjl.tools@gmail.com> Date: Mon Aug 16 16:17:25 2021 -0700 gdb: Don't assume r_ldsomap when r_version > 1 on Linux The r_ldsomap field is specific to Solaris (part of librtld_db), and should never be accessed for Linux. glibc is planning to add a field to support multiple namespaces. But there will be no r_ldsomap when r_version is bumped to 2. Add linux_[ilp32|lp64]_fetch_link_map_offsets to set r_ldsomap_offset to -1 and use them for Linux targets. Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=28236
Fixed.