gdb: show full shared library memory range in 'info sharedlibrary'

On GNU/Linux (and other targets that use solib-svr4.c) the 'info
sharedlibrary' command displays the address range for the .text
section of each library.  This is a fallback behaviour implemented in
solib_map_sections (in solib.c), for targets which are not able to
provide any better information.

The manual doesn't really explain what the address range given means,
and the .text fallback certainly isn't described.  The manual for
'info sharedlibrary' just says:

  'info share REGEX'
  'info sharedlibrary REGEX'
       Print the names of the shared libraries which are currently loaded
       that match REGEX.  If REGEX is omitted then print all shared
       libraries that are loaded.

In this commit I propose that we should change GDB so that the full
library address range is listed for GNU/Linux (and other solib-svr4
targets).  Though it is certainly useful to know where the .text for a
library is, not all code is placed into the .text section, and data,
or course, is stored elsewhere, so the choice of .text, though not a
crazy default, is still a pretty arbitrary choice.

We do also have 'maintenance info sections', which can be used to find
the location of a specific section.  This is of course, a maintenance
command, but we could make this into a real user command if we wanted,
so the information lost by this change to 'info sharedlibrary' is
still available if needed.

There is one small problem.  After this commit, GDB is still under
reporting the extents of some libraries, in some cases.

What I observe is that sometimes, for reasons that I don't currently
understand, the run-time linker will over allocate memory for the .bss
like sections, e.g. the ELF says that 1 page is required, but 2 or 4
pages will be allocated instead.  As a result, GDB will under report
the extent of the library, with the end address being lower than
expected.  This isn't always the case though, in many cases the
allocates are as I would expect, and GDB reports the correct values.

However, as we have been under reporting for many years, I think this
update, which gets things a lot closer to reality, is a big step in
the right direction.  We can always improve the results more later
on if/when the logic behind the over allocations become clearer.

For testing I've compared the output of 'info proc mappings' with the
output of 'info sharedlibrary' (using a script), using GDB to debug
itself, on Fedora Linux running on AArch64, PPC64, S390, and X86-64,
and other than the over allocation problem described above, the
results all look good to me.

Reviewed-By: Eli Zaretskii <eliz@gnu.org>
Approved-By: Simon Marchi <simon.marchi@efficios.com>

3 files changed, 112 insertions, 0 deletions

diff --git a/gdb/NEWS b/gdb/NEWS
index 0aac7a7..42e6de6 100644
--- a/gdb/NEWS
+++ b/gdb/NEWS
@@ -45,6 +45,13 @@ show riscv numeric-register-names
   (e.g 'x1') or their abi names (e.g. 'ra').
   Defaults to 'off', matching the old behaviour (abi names).
 
+* Changed commands
+
+info sharedlibrary
+  On Linux and FreeBSD, the addresses shown in the output of this
+  command are now for the full memory range allocated to the shared
+  library.
+
 * Python API
 
   ** New class gdb.Color for dealing with colors.
diff --git a/gdb/doc/gdb.texinfo b/gdb/doc/gdb.texinfo
index 4734310..e034ac5 100644
--- a/gdb/doc/gdb.texinfo
+++ b/gdb/doc/gdb.texinfo
@@ -22166,6 +22166,12 @@ Print the names of the shared libraries which are currently loaded
 that match @var{regex}.  If @var{regex} is omitted then print
 all shared libraries that are loaded.
 
+For each library, @value{GDBN} also lists the address range allocated
+to that library if it can be determined.  If the address range cannot
+be determined then the address range for the @code{.text} section from
+the library will be listed.  If the @code{.text} section cannot be
+found then no addresses will be listed.
+
 @kindex info dll
 @item info dll @var{regex}
 This is an alias of @code{info sharedlibrary}.
diff --git a/gdb/solib-svr4.c b/gdb/solib-svr4.c
index 8378eca..398123f 100644
--- a/gdb/solib-svr4.c
+++ b/gdb/solib-svr4.c
@@ -3093,6 +3093,37 @@ svr4_truncate_ptr (CORE_ADDR addr)
     return addr & (((CORE_ADDR) 1 << gdbarch_ptr_bit (current_inferior ()->arch ())) - 1);
 }
 
+/* Find the LOAD-able program header in ABFD that contains ASECT.  Return
+   NULL if no such header can be found.  */
+
+static Elf_Internal_Phdr *
+find_loadable_elf_internal_phdr (bfd *abfd, bfd_section *asect)
+{
+  Elf_Internal_Ehdr *ehdr = elf_tdata (abfd)->elf_header;
+  Elf_Internal_Phdr *phdr = elf_tdata (abfd)->phdr;
+
+  for (int i = 0; i < ehdr->e_phnum; i++)
+    {
+      if (phdr[i].p_type == PT_LOAD)
+	{
+	  /* A section without the SEC_LOAD flag is a no-bits section
+	     (e.g. .bss) and has zero size within ABFD.  */
+	  ULONGEST section_file_size
+	    = (((bfd_section_flags (asect) & SEC_LOAD) != 0)
+	       ? bfd_section_size (asect)
+	       : 0);
+
+	  if (asect->filepos >= phdr[i].p_offset
+	      && ((asect->filepos + section_file_size)
+		  <= (phdr[i].p_offset + phdr[i].p_filesz)))
+	    return &phdr[i];
+	}
+    }
+
+  return nullptr;
+}
+
+/* Implement solib_ops::relocate_section_addresses() for svr4 targets.  */
 
 static void
 svr4_relocate_section_addresses (solib &so, target_section *sec)
@@ -3101,6 +3132,74 @@ svr4_relocate_section_addresses (solib &so, target_section *sec)
 
   sec->addr = svr4_truncate_ptr (sec->addr + lm_addr_check (so, abfd));
   sec->endaddr = svr4_truncate_ptr (sec->endaddr + lm_addr_check (so, abfd));
+
+  struct bfd_section *asect = sec->the_bfd_section;
+  gdb_assert (asect != nullptr);
+
+  /* Update the address range of SO based on ASECT.  */
+  if ((bfd_section_flags (asect) & SEC_ALLOC) != 0
+      && bfd_get_flavour (abfd) == bfd_target_elf_flavour)
+    {
+      /* First, SO must cover the contents of ASECT.  */
+      if (so.addr_low == 0 || sec->addr < so.addr_low)
+	so.addr_low = sec->addr;
+
+      if (so.addr_high == 0 || sec->endaddr > so.addr_high)
+	so.addr_high = sec->endaddr;
+
+      gdb_assert (so.addr_low <= so.addr_high);
+
+      /* But we can do better.  Find the program header which contains
+	 ASECT, and figure out its extents.  This gives an larger possible
+	 region for SO.  */
+      Elf_Internal_Phdr *phdr = find_loadable_elf_internal_phdr (abfd, asect);
+
+      if (phdr != nullptr)
+	{
+	  /* Figure out the alignment required by this segment.  */
+	  ULONGEST minpagesize = get_elf_backend_data (abfd)->minpagesize;
+	  ULONGEST segment_alignment
+	    = std::max (minpagesize, static_cast<ULONGEST> (phdr->p_align));
+	  ULONGEST at_pagesz;
+	  if (target_auxv_search (AT_PAGESZ, &at_pagesz) > 0)
+	    segment_alignment = std::max (segment_alignment, at_pagesz);
+
+	  /* The offset of this section within the segment.  */
+	  ULONGEST section_offset = asect->vma - phdr->p_vaddr;
+
+	  /* The start address for the segment, without alignment.  */
+	  CORE_ADDR unaligned_start = sec->addr - section_offset;
+
+	  /* And the start address with downward alignment.  */
+	  CORE_ADDR aligned_start
+	    = align_down (unaligned_start, segment_alignment);
+
+	  /* The end address of the segment depends on its size.  Start
+	     with the size as described in the ELF.  This check of the
+	     memory size and file size is what BFD does, so assume it
+	     knows best and copy this logic.  */
+	  ULONGEST seg_size = std::max (phdr->p_memsz, phdr->p_filesz);
+
+	  /* But by aligning the start address down we need to also include
+	     that difference in the segment size.  */
+	  seg_size += (unaligned_start - aligned_start);
+
+	  /* And align the segment size upward.  */
+	  seg_size = align_up (seg_size, segment_alignment);
+
+	  /* Finally, we can compute the end address.  */
+	  CORE_ADDR end = aligned_start + seg_size;
+
+	  /* And now we can update the extend of SO.  */
+	  if (so.addr_low == 0 || aligned_start < so.addr_low)
+	    so.addr_low = aligned_start;
+
+	  if (so.addr_high == 0 || end > so.addr_high)
+	    so.addr_high = end;
+
+	  gdb_assert (so.addr_low <= so.addr_high);
+	}
+    }
 }