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