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

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