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

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