)]}'
{
  "commit": "65addfb0e40e2057ab0bbfee017fa967e16f2e82",
  "tree": "2e9af0e69b79979dc46ae8a2db6ef45f35a4f4a1",
  "parents": [
    "6a77c6575ff6ab380d962ff970bb031f7df7047d"
  ],
  "author": {
    "name": "Andrew Burgess",
    "email": "aburgess@redhat.com",
    "time": "Tue Mar 04 17:48:37 2025 +0000"
  },
  "committer": {
    "name": "Andrew Burgess",
    "email": "aburgess@redhat.com",
    "time": "Wed Mar 19 14:28:10 2025 +0000"
  },
  "message": "gdb: show full shared library memory range in \u0027info sharedlibrary\u0027\n\nOn GNU/Linux (and other targets that use solib-svr4.c) the \u0027info\nsharedlibrary\u0027 command displays the address range for the .text\nsection of each library.  This is a fallback behaviour implemented in\nsolib_map_sections (in solib.c), for targets which are not able to\nprovide any better information.\n\nThe manual doesn\u0027t really explain what the address range given means,\nand the .text fallback certainly isn\u0027t described.  The manual for\n\u0027info sharedlibrary\u0027 just says:\n\n  \u0027info share REGEX\u0027\n  \u0027info sharedlibrary REGEX\u0027\n       Print the names of the shared libraries which are currently loaded\n       that match REGEX.  If REGEX is omitted then print all shared\n       libraries that are loaded.\n\nIn this commit I propose that we should change GDB so that the full\nlibrary address range is listed for GNU/Linux (and other solib-svr4\ntargets).  Though it is certainly useful to know where the .text for a\nlibrary is, not all code is placed into the .text section, and data,\nor course, is stored elsewhere, so the choice of .text, though not a\ncrazy default, is still a pretty arbitrary choice.\n\nWe do also have \u0027maintenance info sections\u0027, which can be used to find\nthe location of a specific section.  This is of course, a maintenance\ncommand, but we could make this into a real user command if we wanted,\nso the information lost by this change to \u0027info sharedlibrary\u0027 is\nstill available if needed.\n\nThere is one small problem.  After this commit, GDB is still under\nreporting the extents of some libraries, in some cases.\n\nWhat I observe is that sometimes, for reasons that I don\u0027t currently\nunderstand, the run-time linker will over allocate memory for the .bss\nlike sections, e.g. the ELF says that 1 page is required, but 2 or 4\npages will be allocated instead.  As a result, GDB will under report\nthe extent of the library, with the end address being lower than\nexpected.  This isn\u0027t always the case though, in many cases the\nallocates are as I would expect, and GDB reports the correct values.\n\nHowever, as we have been under reporting for many years, I think this\nupdate, which gets things a lot closer to reality, is a big step in\nthe right direction.  We can always improve the results more later\non if/when the logic behind the over allocations become clearer.\n\nFor testing I\u0027ve compared the output of \u0027info proc mappings\u0027 with the\noutput of \u0027info sharedlibrary\u0027 (using a script), using GDB to debug\nitself, on Fedora Linux running on AArch64, PPC64, S390, and X86-64,\nand other than the over allocation problem described above, the\nresults all look good to me.\n\nReviewed-By: Eli Zaretskii \u003celiz@gnu.org\u003e\nApproved-By: Simon Marchi \u003csimon.marchi@efficios.com\u003e\n",
  "tree_diff": [
    {
      "type": "modify",
      "old_id": "0aac7a7b13afd68a09a8eab60eccbbd8e8ca8d36",
      "old_mode": 33188,
      "old_path": "gdb/NEWS",
      "new_id": "42e6de6313d689f7c8db5604f4e1c3522a57c1f4",
      "new_mode": 33188,
      "new_path": "gdb/NEWS"
    },
    {
      "type": "modify",
      "old_id": "473431011d1af0c8e4aaaefcf5028f6f9d7ff07d",
      "old_mode": 33188,
      "old_path": "gdb/doc/gdb.texinfo",
      "new_id": "e034ac53295cd6c3cee24e04b91f6a6398c4b68b",
      "new_mode": 33188,
      "new_path": "gdb/doc/gdb.texinfo"
    },
    {
      "type": "modify",
      "old_id": "8378ecaff40d7de199013578f4b58fe869ba43f8",
      "old_mode": 33188,
      "old_path": "gdb/solib-svr4.c",
      "new_id": "398123f7a520fee54dfd2720c1dedb4194272f25",
      "new_mode": 33188,
      "new_path": "gdb/solib-svr4.c"
    }
  ]
}