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