public inbox for gdb-patches@sourceware.org
 help / color / mirror / Atom feed
From: Kevin Buettner <kevinb@redhat.com>
To: gdb-patches@sourceware.org
Subject: [PATCH v3 1/9] Remove hack for GDB which sets the section size to 0
Date: Wed, 17 Jun 2020 21:08:16 -0700	[thread overview]
Message-ID: <20200618040824.3405657-2-kevinb@redhat.com> (raw)
In-Reply-To: <20200618040824.3405657-1-kevinb@redhat.com>

[Note: This patch has been approved.]

This commit removes a hack for GDB which was introduced in 2007.
See:

    https://sourceware.org/ml/binutils/2007-08/msg00044.html

That hack mostly allowed GDB's handling of core files to continue to
work without any changes to GDB.

The problem with setting the section size to zero is that GDB won't
know how big that section is/was.  Often, this doesn't matter because
the data in question are found in the exec file.  But it can happen
that the section describes memory that had been allocated, but never
written to.  In this instance, the contents of that memory region are
not written to the core file.  Also, since the region in question was
dynamically allocated, it won't appear in the exec file.  We don't
want these regions to appear as inaccessible to GDB (since they *were*
accessible when the process was live), so it's important that GDB know
the size of the region.

I've made changes to GDB which correctly handles this case.  When
attempting to access memory, GDB will first consider core file data
for which both SEC_ALLOC and SEC_HAS_CONTENTS is set.  Next, if that
fails, GDB will attempt to find the data in the exec file.  Finally,
if that also fails, GDB will attempt to access memory in the sections
which are flagged as SEC_ALLOC, but not SEC_HAS_CONTENTS.

bfd/ChangeLog:

	* elf.c (_bfd_elf_make_section_from_phdr): Remove hack for GDB.
---
 bfd/elf.c | 8 --------
 1 file changed, 8 deletions(-)

diff --git a/bfd/elf.c b/bfd/elf.c
index e9c525974b..f54d693b09 100644
--- a/bfd/elf.c
+++ b/bfd/elf.c
@@ -3025,14 +3025,6 @@ _bfd_elf_make_section_from_phdr (bfd *abfd,
       newsect->alignment_power = bfd_log2 (align);
       if (hdr->p_type == PT_LOAD)
 	{
-	  /* Hack for gdb.  Segments that have not been modified do
-	     not have their contents written to a core file, on the
-	     assumption that a debugger can find the contents in the
-	     executable.  We flag this case by setting the fake
-	     section size to zero.  Note that "real" bss sections will
-	     always have their contents dumped to the core file.  */
-	  if (bfd_get_format (abfd) == bfd_core)
-	    newsect->size = 0;
 	  newsect->flags |= SEC_ALLOC;
 	  if (hdr->p_flags & PF_X)
 	    newsect->flags |= SEC_CODE;
-- 
2.26.2


  reply	other threads:[~2020-06-18  4:09 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 ` Kevin Buettner [this message]
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 ` [PATCH v3 6/9] Update binary_get_section_contents to seek using section's file position Kevin Buettner
2020-06-18 10:25   ` 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-2-kevinb@redhat.com \
    --to=kevinb@redhat.com \
    --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).