Blame SOURCES/gdb-rhbz1842691-corefile-mem-access-6of15.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 17:32:50 -0400
0efd7d
Subject: gdb-rhbz1842691-corefile-mem-access-6of15.patch
0efd7d
0efd7d
;; Update binary_get_section_contents to seek using section's file position
0efd7d
;; Kevin Buettner, RH BZ 1842961
0efd7d
0efd7d
   Author: Kevin Buettner <kevinb@redhat.com>
0efd7d
   Date:   Thu Jun 11 18:58:49 2020 -0700
0efd7d
0efd7d
    Update binary_get_section_contents to seek using section's file position
0efd7d
0efd7d
    I have a patch for GDB which opens and reads from BFDs using the
0efd7d
    "binary" target.  However, for it to work, we need to be able to get a
0efd7d
    section's contents based from the file position of that section.
0efd7d
0efd7d
    At the moment, reading a section's contents will always read from the
0efd7d
    start of the file regardless of where that section is located.  While
0efd7d
    this was fine for the original use of the "binary" target, it won't
0efd7d
    work for my use case.  This change shouldn't impact any existing
0efd7d
    callers due to the fact that the single .data section is initialized
0efd7d
    with a filepos of 0.
0efd7d
0efd7d
    bfd/ChangeLog:
0efd7d
0efd7d
    	* binary.c (binary_get_section_contents): Seek using offset
0efd7d
    	from section's file position.
0efd7d
0efd7d
diff --git a/bfd/binary.c b/bfd/binary.c
0efd7d
--- a/bfd/binary.c
0efd7d
+++ b/bfd/binary.c
0efd7d
@@ -19,10 +19,10 @@
0efd7d
    Foundation, Inc., 51 Franklin Street - Fifth Floor, Boston,
0efd7d
    MA 02110-1301, USA.  */
0efd7d
 
0efd7d
-/* This is a BFD backend which may be used to write binary objects.
0efd7d
-   It may only be used for output, not input.  The intention is that
0efd7d
-   this may be used as an output format for objcopy in order to
0efd7d
-   generate raw binary data.
0efd7d
+/* This is a BFD backend which may be used to read or write binary
0efd7d
+   objects.  Historically, it was used as an output format for objcopy
0efd7d
+   in order to generate raw binary data, but is now used for other
0efd7d
+   purposes as well.
0efd7d
 
0efd7d
    This is very simple.  The only complication is that the real data
0efd7d
    will start at some address X, and in some cases we will not want to
0efd7d
@@ -97,12 +97,12 @@ binary_object_p (bfd *abfd)
0efd7d
 
0efd7d
 static bfd_boolean
0efd7d
 binary_get_section_contents (bfd *abfd,
0efd7d
-			     asection *section ATTRIBUTE_UNUSED,
0efd7d
+			     asection *section,
0efd7d
 			     void * location,
0efd7d
 			     file_ptr offset,
0efd7d
 			     bfd_size_type count)
0efd7d
 {
0efd7d
-  if (bfd_seek (abfd, offset, SEEK_SET) != 0
0efd7d
+  if (bfd_seek (abfd, section->filepos + offset, SEEK_SET) != 0
0efd7d
       || bfd_bread (location, count, abfd) != count)
0efd7d
     return FALSE;
0efd7d
   return TRUE;