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

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