public inbox for binutils@sourceware.org
 help / color / mirror / Atom feed
From: Alan Modra <amodra@bigpond.net.au>
To: Jan Kratochvil <jan.kratochvil@redhat.com>,
		Roland McGrath <roland@redhat.com>,
	binutils@sources.redhat.com
Subject: Re: [patch] bfd: Core files with p_filesz < p_memsz (build-id)
Date: Fri, 03 Aug 2007 02:50:00 -0000	[thread overview]
Message-ID: <20070803025000.GB11213@bubble.grove.modra.org> (raw)
In-Reply-To: <20070803002103.GA19863@caradoc.them.org>

On Thu, Aug 02, 2007 at 08:21:03PM -0400, Daniel Jacobowitz wrote:
> On Fri, Aug 03, 2007 at 09:43:00AM +0930, Alan Modra wrote:
> > Oh, I see.  I was just looking at the split case.  I'd say the
> > non-split behaviour is a bug.  A program header with p_filesz zero and
> > p_memsz non-zero really ought to create a bfd section with size equal
> > to p_memsz, without SEC_HAS_CONTENTS and SEC_LOAD.
> > 
> > So I think we should apply the following, and possibly on top of this
> > do something special for core files.
> 
> Yes, I agree.  But keep in mind that this patch on its own is going to
> lay waste to GDB's core debugging :-)  It will now disassemble all
> functions as zeroes.
> 
> What we really want in GDB is now a bit complicated:
>   - Prefer data from core file if within p_filesz.
>   - Prefer data from executable if between p_filesz and p_memsz.
>   - Show zeroes (rather than read errors) for data between p_filesz
>     and p_memsz if not present in the executable.
> 
> Messy...

I'd be happy with the following.  Please check that this doesn't break
gdb..

	* elf.c (_bfd_elf_make_section_from_phdr): Properly handle
	bss segments.

Index: bfd/elf.c
===================================================================
RCS file: /cvs/src/src/bfd/elf.c,v
retrieving revision 1.404
diff -u -p -w -r1.404 elf.c
--- bfd/elf.c	1 Aug 2007 19:55:10 -0000	1.404
+++ bfd/elf.c	3 Aug 2007 02:44:28 -0000
@@ -2223,7 +2223,7 @@ _bfd_elf_new_section_hook (bfd *abfd, as
    for the single program segment.  The first has the length specified by
    the file size of the segment, and the second has the length specified
    by the difference between the two sizes.  In effect, the segment is split
-   into it's initialized and uninitialized parts.
+   into its initialized and uninitialized parts.
 
  */
 
@@ -2242,6 +2242,9 @@ _bfd_elf_make_section_from_phdr (bfd *ab
   split = ((hdr->p_memsz > 0)
 	    && (hdr->p_filesz > 0)
 	    && (hdr->p_memsz > hdr->p_filesz));
+
+  if (hdr->p_filesz > 0)
+    {
   sprintf (namebuf, "%s%d%s", typename, index, split ? "a" : "");
   len = strlen (namebuf) + 1;
   name = bfd_alloc (abfd, len);
@@ -2272,10 +2275,13 @@ _bfd_elf_make_section_from_phdr (bfd *ab
     {
       newsect->flags |= SEC_READONLY;
     }
+    }
 
-  if (split)
+  if (hdr->p_memsz > hdr->p_filesz)
     {
-      sprintf (namebuf, "%s%db", typename, index);
+      bfd_vma align;
+
+      sprintf (namebuf, "%s%d%s", typename, index, split ? "b" : "");
       len = strlen (namebuf) + 1;
       name = bfd_alloc (abfd, len);
       if (!name)
@@ -2287,8 +2293,21 @@ _bfd_elf_make_section_from_phdr (bfd *ab
       newsect->vma = hdr->p_vaddr + hdr->p_filesz;
       newsect->lma = hdr->p_paddr + hdr->p_filesz;
       newsect->size = hdr->p_memsz - hdr->p_filesz;
+      newsect->filepos = hdr->p_offset + hdr->p_filesz;
+      align = newsect->vma & -newsect->vma;
+      if (align == 0 || align > hdr->p_align)
+	align = hdr->p_align;
+      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;

-- 
Alan Modra
Australia Development Lab, IBM

  reply	other threads:[~2007-08-03  2:50 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-07-28 20:16 Jan Kratochvil
2007-07-29 12:30 ` Jan Kratochvil
2007-07-29 15:29 ` Roland McGrath
2007-07-29 18:32   ` Jan Kratochvil
2007-08-01 13:05     ` Alan Modra
2007-08-02 20:03       ` Daniel Jacobowitz
2007-08-03  0:13         ` Alan Modra
2007-08-03  0:21           ` Daniel Jacobowitz
2007-08-03  2:50             ` Alan Modra [this message]
2007-08-06 19:32               ` Daniel Jacobowitz
2007-08-09 16:04               ` Jan Kratochvil
2007-07-30 14:07 ` [resent] " Jan Kratochvil

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=20070803025000.GB11213@bubble.grove.modra.org \
    --to=amodra@bigpond.net.au \
    --cc=binutils@sources.redhat.com \
    --cc=jan.kratochvil@redhat.com \
    --cc=roland@redhat.com \
    /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).