Blame SOURCES/gdb-rhbz1842691-corefile-mem-access-1of15.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 16:34:37 -0400
46818e
Subject: gdb-rhbz1842691-corefile-mem-access-1of15.patch
46818e
46818e
;; Remove hack for GDB which sets the section size to 0
46818e
;; Kevin Buettner, RH BZ 1842691
46818e
46818e
    Author: Kevin Buettner <kevinb@redhat.com>
46818e
46818e
    Remove hack for GDB which sets the section size to 0
46818e
46818e
    This commit removes a hack for GDB which was introduced in 2007.
46818e
    See:
46818e
46818e
        https://sourceware.org/ml/binutils/2007-08/msg00044.html
46818e
46818e
    That hack mostly allowed GDB's handling of core files to continue to
46818e
    work without any changes to GDB.
46818e
46818e
    The problem with setting the section size to zero is that GDB won't
46818e
    know how big that section is/was.  Often, this doesn't matter because
46818e
    the data in question are found in the exec file.  But it can happen
46818e
    that the section describes memory that had been allocated, but never
46818e
    written to.  In this instance, the contents of that memory region are
46818e
    not written to the core file.  Also, since the region in question was
46818e
    dynamically allocated, it won't appear in the exec file.  We don't
46818e
    want these regions to appear as inaccessible to GDB (since they *were*
46818e
    accessible when the process was live), so it's important that GDB know
46818e
    the size of the region.
46818e
46818e
    I've made changes to GDB which correctly handles this case.  When
46818e
    attempting to access memory, GDB will first consider core file data
46818e
    for which both SEC_ALLOC and SEC_HAS_CONTENTS is set.  Next, if that
46818e
    fails, GDB will attempt to find the data in the exec file.  Finally,
46818e
    if that also fails, GDB will attempt to access memory in the sections
46818e
    which are flagged as SEC_ALLOC, but not SEC_HAS_CONTENTS.
46818e
46818e
    bfd/ChangeLog:
46818e
46818e
        * elf.c (_bfd_elf_make_section_from_phdr): Remove hack for GDB.
46818e
46818e
diff --git a/bfd/elf.c b/bfd/elf.c
46818e
--- a/bfd/elf.c
46818e
+++ b/bfd/elf.c
46818e
@@ -3032,14 +3032,6 @@ _bfd_elf_make_section_from_phdr (bfd *abfd,
46818e
       newsect->alignment_power = bfd_log2 (align);
46818e
       if (hdr->p_type == PT_LOAD)
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
 	  newsect->flags |= SEC_ALLOC;
46818e
 	  if (hdr->p_flags & PF_X)
46818e
 	    newsect->flags |= SEC_CODE;