Blame SOURCES/gdb-rhbz1842691-corefile-mem-access-12of15.patch

0efd7d
From FEDORA_PATCHES Mon Sep 17 00:00:00 2001
0efd7d
From: Keith Seitz <keiths@redhat.com>
0efd7d
Date: Tue, 28 Jul 2020 09:32:50 -0400
0efd7d
Subject: gdb-rhbz1842691-corefile-mem-access-12of15.patch
0efd7d
0efd7d
;; Add new command "maint print core-file-backed-mappings"
0efd7d
;; Kevin Buettner, RH BZ 1842961
0efd7d
0efd7d
   Author: Kevin Buettner <kevinb@redhat.com>
0efd7d
   Date:   Fri Jul 3 21:55:51 2020 -0700
0efd7d
0efd7d
    Add new command "maint print core-file-backed-mappings"
0efd7d
0efd7d
    I wrote a read_core_file_mappings method for FreeBSD and then registered
0efd7d
    this gdbarch method.  I saw some strange behavior while testing it and
0efd7d
    wanted a way to make sure that mappings were being correctly loaded
0efd7d
    into corelow.c, so I wrote the new command which is the topic of this
0efd7d
    commit.  I think it might be occasionally useful for debugging strange
0efd7d
    corefile behavior.
0efd7d
0efd7d
    With regard to FreeBSD, my work isn't ready yet.  Unlike Linux,
0efd7d
    FreeBSD puts all mappings into its core file note.  And, unlike Linux,
0efd7d
    it doesn't dump load segments which occupy no space in the file.  So
0efd7d
    my (perhaps naive) implementation of a FreeBSD read_core_file_mappings
0efd7d
    didn't work all that well:  I saw more failures in the corefile2.exp
0efd7d
    tests than without it.  I think it should be possible to make FreeBSD
0efd7d
    work as well as Linux, but it will require doing something with all of
0efd7d
    the mappings, not just the file based mappings that I was considering.
0efd7d
0efd7d
    In the v4 series, Pedro asked the following:
0efd7d
0efd7d
        I don't understand what this command provides that "info proc
0efd7d
        mappings" doesn't?  Can you give an example of when you'd use this
0efd7d
        command over "info proc mappings" ?
0efd7d
0efd7d
    On Linux, "info proc mappings" and "maint print core-file-backed-mappings"
0efd7d
    will produce similar, possibly identical, output.  This need not be
0efd7d
    the case for other OSes.  E.g. on FreeBSD, had I finished the
0efd7d
    implementation, the output from these commands would have been very
0efd7d
    different.  The FreeBSD "info proc mappings" command would show
0efd7d
    additional (non-file-backed) mappings in addition to at least one
0efd7d
    additional field (memory permissions) for each mapping.
0efd7d
0efd7d
    As noted earlier, I was seeing some unexpected behavior while working
0efd7d
    on the FreeBSD implementation and wanted to be certain that the
0efd7d
    mappings were being correctly loaded by corelow.c.  "info proc
0efd7d
    mappings" prints the core file mappings, but doesn't tell us anything
0efd7d
    about whether they've been loaded by corelow.c This new maintenance
0efd7d
    command directly interrogates the data structures and prints the
0efd7d
    values found there.
0efd7d
0efd7d
    gdb/ChangeLog:
0efd7d
0efd7d
    	* corelow.c (gdbcmd.h): Include.
0efd7d
    	(core_target::info_proc_mappings): New method.
0efd7d
    	(get_current_core_target): New function.
0efd7d
    	(maintenance_print_core_file_backed_mappings): New function.
0efd7d
    	(_initialize_corelow): Add core-file-backed-mappings to
0efd7d
    	"maint print" commands.
0efd7d
0efd7d
diff --git a/gdb/corelow.c b/gdb/corelow.c
0efd7d
--- a/gdb/corelow.c
0efd7d
+++ b/gdb/corelow.c
0efd7d
@@ -51,6 +51,7 @@
0efd7d
 #include "build-id.h"
0efd7d
 #include "gdbsupport/pathstuff.h"
0efd7d
 #include <unordered_map>
0efd7d
+#include "gdbcmd.h"
0efd7d
 
0efd7d
 #ifndef O_LARGEFILE
0efd7d
 #define O_LARGEFILE 0
0efd7d
@@ -121,6 +122,9 @@ public:
0efd7d
 				  const char *human_name,
0efd7d
 				  bool required);
0efd7d
 
0efd7d
+  /* See definition.  */
0efd7d
+  void info_proc_mappings (struct gdbarch *gdbarch);
0efd7d
+
0efd7d
 private: /* per-core data */
0efd7d
 
0efd7d
   /* The core's section table.  Note that these target sections are
0efd7d
@@ -1170,6 +1174,86 @@ core_target::info_proc (const char *args, enum info_proc_what request)
0efd7d
   return true;
0efd7d
 }
0efd7d
 
0efd7d
+/* Get a pointer to the current core target.  If not connected to a
0efd7d
+   core target, return NULL.  */
0efd7d
+
0efd7d
+static core_target *
0efd7d
+get_current_core_target ()
0efd7d
+{
0efd7d
+  target_ops *proc_target = find_target_at (process_stratum);
0efd7d
+  return dynamic_cast<core_target *> (proc_target);
0efd7d
+}
0efd7d
+
0efd7d
+/* Display file backed mappings from core file.  */
0efd7d
+
0efd7d
+void
0efd7d
+core_target::info_proc_mappings (struct gdbarch *gdbarch)
0efd7d
+{
0efd7d
+  if (m_core_file_mappings.sections != m_core_file_mappings.sections_end)
0efd7d
+    {
0efd7d
+      printf_filtered (_("Mapped address spaces:\n\n"));
0efd7d
+      if (gdbarch_addr_bit (gdbarch) == 32)
0efd7d
+	{
0efd7d
+	  printf_filtered ("\t%10s %10s %10s %10s %s\n",
0efd7d
+			   "Start Addr",
0efd7d
+			   "  End Addr",
0efd7d
+			   "      Size", "    Offset", "objfile");
0efd7d
+	}
0efd7d
+      else
0efd7d
+	{
0efd7d
+	  printf_filtered ("  %18s %18s %10s %10s %s\n",
0efd7d
+			   "Start Addr",
0efd7d
+			   "  End Addr",
0efd7d
+			   "      Size", "    Offset", "objfile");
0efd7d
+	}
0efd7d
+    }
0efd7d
+
0efd7d
+  for (const struct target_section *tsp = m_core_file_mappings.sections;
0efd7d
+       tsp < m_core_file_mappings.sections_end;
0efd7d
+       tsp++)
0efd7d
+    {
0efd7d
+      ULONGEST start = tsp->addr;
0efd7d
+      ULONGEST end = tsp->endaddr;
0efd7d
+      ULONGEST file_ofs = tsp->the_bfd_section->filepos;
0efd7d
+      const char *filename = bfd_get_filename (tsp->the_bfd_section->owner);
0efd7d
+
0efd7d
+      if (gdbarch_addr_bit (gdbarch) == 32)
0efd7d
+	printf_filtered ("\t%10s %10s %10s %10s %s\n",
0efd7d
+			 paddress (gdbarch, start),
0efd7d
+			 paddress (gdbarch, end),
0efd7d
+			 hex_string (end - start),
0efd7d
+			 hex_string (file_ofs),
0efd7d
+			 filename);
0efd7d
+      else
0efd7d
+	printf_filtered ("  %18s %18s %10s %10s %s\n",
0efd7d
+			 paddress (gdbarch, start),
0efd7d
+			 paddress (gdbarch, end),
0efd7d
+			 hex_string (end - start),
0efd7d
+			 hex_string (file_ofs),
0efd7d
+			 filename);
0efd7d
+    }
0efd7d
+}
0efd7d
+
0efd7d
+/* Implement "maintenance print core-file-backed-mappings" command.  
0efd7d
+
0efd7d
+   If mappings are loaded, the results should be similar to the
0efd7d
+   mappings shown by "info proc mappings".  This command is mainly a
0efd7d
+   debugging tool for GDB developers to make sure that the expected
0efd7d
+   mappings are present after loading a core file.  For Linux, the
0efd7d
+   output provided by this command will be very similar (if not
0efd7d
+   identical) to that provided by "info proc mappings".  This is not
0efd7d
+   necessarily the case for other OSes which might provide
0efd7d
+   more/different information in the "info proc mappings" output.  */
0efd7d
+
0efd7d
+static void
0efd7d
+maintenance_print_core_file_backed_mappings (const char *args, int from_tty)
0efd7d
+{
0efd7d
+  core_target *targ = get_current_core_target ();
0efd7d
+  if (targ != nullptr)
0efd7d
+    targ->info_proc_mappings (targ->core_gdbarch ());
0efd7d
+}
0efd7d
+
0efd7d
+void _initialize_corelow ();
0efd7d
 void
0efd7d
 _initialize_corelow (void)
0efd7d
 {
0efd7d
@@ -1181,4 +1265,8 @@ Set whether CORE-FILE loads the build-id associated files automatically."), _("\
0efd7d
 Show whether CORE-FILE loads the build-id associated files automatically."),
0efd7d
 			   NULL, NULL, NULL,
0efd7d
 			   &setlist, &showlist);
0efd7d
+  add_cmd ("core-file-backed-mappings", class_maintenance,
0efd7d
+           maintenance_print_core_file_backed_mappings,
0efd7d
+	   _("Print core file's file-backed mappings"),
0efd7d
+	   &maintenanceprintlist);
0efd7d
 }