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

46818e
From FEDORA_PATCHES Mon Sep 17 00:00:00 2001
46818e
From: Keith Seitz <keiths@redhat.com>
46818e
Date: Mon, 27 Jul 2020 17:11:49 -0400
46818e
Subject: gdb-rhbz1842691-corefile-mem-access-4of15.patch
46818e
46818e
;; Provide access to non SEC_HAS_CONTENTS core file sections
46818e
;; Kevin Buettner, RH BZ 1842961
46818e
46818e
   Author: Kevin Buettner <kevinb@redhat.com>
46818e
   Date:   Wed Mar 4 17:42:42 2020 -0700
46818e
46818e
    Provide access to non SEC_HAS_CONTENTS core file sections
46818e
46818e
    Consider the following program:
46818e
46818e
    - - - mkmmapcore.c - - -
46818e
46818e
    static char *buf;
46818e
46818e
    int
46818e
    main (int argc, char **argv)
46818e
    {
46818e
      buf = mmap (NULL, 8192, PROT_READ | PROT_WRITE,
46818e
                  MAP_ANONYMOUS | MAP_PRIVATE, -1, 0);
46818e
      abort ();
46818e
    }
46818e
    - - - end mkmmapcore.c - - -
46818e
46818e
    Compile it like this:
46818e
46818e
    gcc -g -o mkmmapcore mkmmapcore.c
46818e
46818e
    Now let's run it from GDB.  I've already placed a breakpoint on the
46818e
    line with the abort() call and have run to that breakpoint.
46818e
46818e
    Breakpoint 1, main (argc=1, argv=0x7fffffffd678) at mkmmapcore.c:11
46818e
    11	  abort ();
46818e
    (gdb) x/x buf
46818e
    0x7ffff7fcb000:	0x00000000
46818e
46818e
    Note that we can examine the memory allocated via the call to mmap().
46818e
46818e
    Now let's try debugging a core file created by running this program.
46818e
    Depending on your system, in order to make a core file, you may have to
46818e
    run the following as root (or using sudo):
46818e
46818e
        echo core > /proc/sys/kernel/core_pattern
46818e
46818e
    It may also be necessary to do:
46818e
46818e
        ulimit -c unlimited
46818e
46818e
    I'm using Fedora 31. YMMV if you're using one of the BSDs or some other
46818e
    (non-Linux) system.
46818e
46818e
    This is what things look like when we debug the core file:
46818e
46818e
        [kev@f31-1 tmp]$ gdb -q ./mkmmapcore core.304767
46818e
        Reading symbols from ./mkmmapcore...
46818e
        [New LWP 304767]
46818e
        Core was generated by `/tmp/mkmmapcore'.
46818e
        Program terminated with signal SIGABRT, Aborted.
46818e
        #0  __GI_raise (sig=sig@entry=6) at ../sysdeps/unix/sysv/linux/raise.c:50
46818e
        50	  return ret;
46818e
        (gdb) x/x buf
46818e
        0x7ffff7fcb000:	Cannot access memory at address 0x7ffff7fcb000
46818e
46818e
    Note that we can no longer access the memory region allocated by mmap().
46818e
46818e
    Back in 2007, a hack for GDB was added to _bfd_elf_make_section_from_phdr()
46818e
    in bfd/elf.c:
46818e
46818e
    	  /* Hack for gdb.  Segments that have not been modified do
46818e
    	     not have their contents written to a core file, on the
46818e
    	     assumption that a debugger can find the contents in the
46818e
    	     executable.  We flag this case by setting the fake
46818e
    	     section size to zero.  Note that "real" bss sections will
46818e
    	     always have their contents dumped to the core file.  */
46818e
    	  if (bfd_get_format (abfd) == bfd_core)
46818e
    	    newsect->size = 0;
46818e
46818e
    You can find the entire patch plus links to other discussion starting
46818e
    here:
46818e
46818e
        https://sourceware.org/ml/binutils/2007-08/msg00047.html
46818e
46818e
    This hack sets the size of certain BFD sections to 0, which
46818e
    effectively causes GDB to ignore them.  I think it's likely that the
46818e
    bug described above existed even before this hack was added, but I
46818e
    have no easy way to test this now.
46818e
46818e
    The output from objdump -h shows the result of this hack:
46818e
46818e
     25 load13        00000000  00007ffff7fcb000  0000000000000000  00013000  2**12
46818e
                      ALLOC
46818e
46818e
    (The first field, after load13, shows the size of 0.)
46818e
46818e
    Once the hack is removed, the output from objdump -h shows the correct
46818e
    size:
46818e
46818e
     25 load13        00002000  00007ffff7fcb000  0000000000000000  00013000  2**12
46818e
                      ALLOC
46818e
46818e
    (This is a digression, but I think it's good that objdump will now show
46818e
    the correct size.)
46818e
46818e
    If we remove the hack from bfd/elf.c, but do nothing to GDB, we'll
46818e
    see the following regression:
46818e
46818e
    FAIL: gdb.base/corefile.exp: print coremaker_ro
46818e
46818e
    The reason for this is that all sections which have the BFD flag
46818e
    SEC_ALLOC set, but for which SEC_HAS_CONTENTS is not set no longer
46818e
    have zero size.  Some of these sections have data that can (and should)
46818e
    be read from the executable.  (Sections for which SEC_HAS_CONTENTS
46818e
    is set should be read from the core file; sections which do not have
46818e
    this flag set need to either be read from the executable or, failing
46818e
    that, from the core file using whatever BFD decides is the best value
46818e
    to present to the user - it uses zeros.)
46818e
46818e
    At present, due to the way that the target strata are traversed when
46818e
    attempting to access memory, the non-SEC_HAS_CONTENTS sections will be
46818e
    read as zeroes from the process_stratum (which in this case is the
46818e
    core file stratum) without first checking the file stratum, which is
46818e
    where the data might actually be found.
46818e
46818e
    What we should be doing is this:
46818e
46818e
    - Attempt to access core file data for SEC_HAS_CONTENTS sections.
46818e
    - Attempt to access executable file data if the above fails.
46818e
    - Attempt to access core file data for non SEC_HAS_CONTENTS sections, if
46818e
      both of the above fail.
46818e
46818e
    This corresponds to the analysis of Daniel Jacobowitz back in 2007
46818e
    when the hack was added to BFD:
46818e
46818e
        https://sourceware.org/legacy-ml/binutils/2007-08/msg00045.html
46818e
46818e
    The difference, observed by Pedro in his review of my v1 patches, is
46818e
    that I'm using "the section flags as proxy for the p_filesz/p_memsz
46818e
    checks."
46818e
46818e
    gdb/ChangeLog:
46818e
46818e
    	PR corefiles/25631
46818e
    	* corelow.c (core_target:xfer_partial):  Revise
46818e
    	TARGET_OBJECT_MEMORY case to consider non-SEC_HAS_CONTENTS
46818e
    	case after first checking the stratum beneath the core
46818e
    	target.
46818e
    	(has_all_memory): Return true.
46818e
    	* target.c (raw_memory_xfer_partial): Revise comment
46818e
    	regarding use of has_all_memory.
46818e
46818e
diff --git a/gdb/corelow.c b/gdb/corelow.c
46818e
--- a/gdb/corelow.c
46818e
+++ b/gdb/corelow.c
46818e
@@ -93,7 +93,7 @@ public:
46818e
 
46818e
   const char *thread_name (struct thread_info *) override;
46818e
 
46818e
-  bool has_all_memory () override { return false; }
46818e
+  bool has_all_memory () override { return true; }
46818e
   bool has_memory () override;
46818e
   bool has_stack () override;
46818e
   bool has_registers () override;
46818e
@@ -754,12 +754,47 @@ core_target::xfer_partial (enum target_object object, const char *annex,
46818e
   switch (object)
46818e
     {
46818e
     case TARGET_OBJECT_MEMORY:
46818e
-      return (section_table_xfer_memory_partial
46818e
-	      (readbuf, writebuf,
46818e
-	       offset, len, xfered_len,
46818e
-	       m_core_section_table.sections,
46818e
-	       m_core_section_table.sections_end));
46818e
+      {
46818e
+	enum target_xfer_status xfer_status;
46818e
+
46818e
+	/* Try accessing memory contents from core file data,
46818e
+	   restricting consideration to those sections for which
46818e
+	   the BFD section flag SEC_HAS_CONTENTS is set.  */
46818e
+	auto has_contents_cb = [] (const struct target_section *s)
46818e
+	  {
46818e
+	    return ((s->the_bfd_section->flags & SEC_HAS_CONTENTS) != 0);
46818e
+	  };
46818e
+	xfer_status = section_table_xfer_memory_partial
46818e
+			(readbuf, writebuf,
46818e
+			 offset, len, xfered_len,
46818e
+			 m_core_section_table.sections,
46818e
+			 m_core_section_table.sections_end,
46818e
+			 has_contents_cb);
46818e
+	if (xfer_status == TARGET_XFER_OK)
46818e
+	  return TARGET_XFER_OK;
46818e
+
46818e
+	/* Now check the stratum beneath us; this should be file_stratum.  */
46818e
+	xfer_status = this->beneath ()->xfer_partial (object, annex, readbuf,
46818e
+						      writebuf, offset, len,
46818e
+						      xfered_len);
46818e
+	if (xfer_status == TARGET_XFER_OK)
46818e
+	  return TARGET_XFER_OK;
46818e
 
46818e
+	/* Finally, attempt to access data in core file sections with
46818e
+	   no contents.  These will typically read as all zero.  */
46818e
+	auto no_contents_cb = [&] (const struct target_section *s)
46818e
+	  {
46818e
+	    return !has_contents_cb (s);
46818e
+	  };
46818e
+	xfer_status = section_table_xfer_memory_partial
46818e
+			(readbuf, writebuf,
46818e
+			 offset, len, xfered_len,
46818e
+			 m_core_section_table.sections,
46818e
+			 m_core_section_table.sections_end,
46818e
+			 no_contents_cb);
46818e
+
46818e
+	return xfer_status;
46818e
+      }
46818e
     case TARGET_OBJECT_AUXV:
46818e
       if (readbuf)
46818e
 	{
46818e
diff --git a/gdb/target.c b/gdb/target.c
46818e
--- a/gdb/target.c
46818e
+++ b/gdb/target.c
46818e
@@ -967,8 +967,11 @@ raw_memory_xfer_partial (struct target_ops *ops, gdb_byte *readbuf,
46818e
       if (res == TARGET_XFER_UNAVAILABLE)
46818e
 	break;
46818e
 
46818e
-      /* We want to continue past core files to executables, but not
46818e
-	 past a running target's memory.  */
46818e
+      /* Don't continue past targets which have all the memory.
46818e
+         At one time, this code was necessary to read data from
46818e
+	 executables / shared libraries when data for the requested
46818e
+	 addresses weren't available in the core file.  But now the
46818e
+	 core target handles this case itself.  */
46818e
       if (ops->has_all_memory ())
46818e
 	break;
46818e