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

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