public inbox for gdb-patches@sourceware.org
 help / color / mirror / Atom feed
From: Kevin Buettner <kevinb@redhat.com>
To: gdb-patches@sourceware.org
Cc: Kevin Buettner <kevinb@redhat.com>, binutils@sourceware.org
Subject: [PATCH v3 6/9] Update binary_get_section_contents to seek using section's file position
Date: Wed, 17 Jun 2020 21:08:22 -0700	[thread overview]
Message-ID: <20200618040824.3405657-7-kevinb@redhat.com> (raw)
In-Reply-To: <20200618040824.3405657-1-kevinb@redhat.com>

[Note: This patch requires approval from a binutils maintainer.]

I have a patch for GDB which opens and reads from BFDs using the
"binary" target.  However, for it to work, we need to be able to get a
section's contents based from the file position of that section.

At the moment, reading a section's contents will always read from the
start of the file regardless of where that section is located.  While
this was fine for the original use of the "binary" target, it won't
work for my use case.  This change shouldn't impact any existing
callers due to the fact that the single .data section is initialized
with a filepos of 0.

bfd/ChangeLog:

	* binary.c (binary_get_section_contents): Seek using offset
	from section's file position.
---
 bfd/binary.c | 12 ++++++------
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/bfd/binary.c b/bfd/binary.c
index 999de0d8c4..e872924a2d 100644
--- a/bfd/binary.c
+++ b/bfd/binary.c
@@ -19,10 +19,10 @@
    Foundation, Inc., 51 Franklin Street - Fifth Floor, Boston,
    MA 02110-1301, USA.  */
 
-/* This is a BFD backend which may be used to write binary objects.
-   It may only be used for output, not input.  The intention is that
-   this may be used as an output format for objcopy in order to
-   generate raw binary data.
+/* This is a BFD backend which may be used to read or write binary
+   objects.  Historically, it was used as an output format for objcopy
+   in order to generate raw binary data, but is now used for other
+   purposes as well.
 
    This is very simple.  The only complication is that the real data
    will start at some address X, and in some cases we will not want to
@@ -97,12 +97,12 @@ binary_object_p (bfd *abfd)
 
 static bfd_boolean
 binary_get_section_contents (bfd *abfd,
-			     asection *section ATTRIBUTE_UNUSED,
+			     asection *section,
 			     void * location,
 			     file_ptr offset,
 			     bfd_size_type count)
 {
-  if (bfd_seek (abfd, offset, SEEK_SET) != 0
+  if (bfd_seek (abfd, section->filepos + offset, SEEK_SET) != 0
       || bfd_bread (location, count, abfd) != count)
     return FALSE;
   return TRUE;
-- 
2.26.2


  parent reply	other threads:[~2020-06-18  4:12 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-06-18  4:08 [PATCH v3 0/9] Fix BZ 25631 - core file memory access problem Kevin Buettner
2020-06-18  4:08 ` [PATCH v3 1/9] Remove hack for GDB which sets the section size to 0 Kevin Buettner
2020-06-18  4:08 ` [PATCH v3 2/9] Adjust corefile.exp test to show regression after bfd hack removal Kevin Buettner
2020-06-18  4:08 ` [PATCH v3 3/9] section_table_xfer_memory: Replace section name with callback predicate Kevin Buettner
2020-06-18  4:08 ` [PATCH v3 4/9] Provide access to non SEC_HAS_CONTENTS core file sections Kevin Buettner
2020-06-18  4:08 ` [PATCH v3 5/9] Test ability to access unwritten-to mmap data in core file Kevin Buettner
2020-06-25 14:32   ` Pedro Alves
2020-06-18  4:08 ` Kevin Buettner [this message]
2020-06-18 10:25   ` [PATCH v3 6/9] Update binary_get_section_contents to seek using section's file position Nick Clifton
2020-06-18  4:08 ` [PATCH v3 7/9] Use NT_FILE note section for reading core target memory Kevin Buettner
2020-06-25 14:11   ` Pedro Alves
2020-06-18  4:08 ` [PATCH v3 8/9] Add test for accessing read-only mmapped data in a core file Kevin Buettner
2020-06-18  4:08 ` [PATCH v3 9/9] New core file tests with mappings over existing program memory Kevin Buettner
2020-06-24  2:44   ` Kevin Buettner
2020-06-25 14:12     ` Pedro Alves
2020-06-25 14:15 ` [PATCH v3 0/9] Fix BZ 25631 - core file memory access problem Pedro Alves

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20200618040824.3405657-7-kevinb@redhat.com \
    --to=kevinb@redhat.com \
    --cc=binutils@sourceware.org \
    --cc=gdb-patches@sourceware.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).