|
|
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;
|