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>

0 files changed, 0 insertions, 0 deletions