Mirror of the gdb mailing list
 help / color / mirror / Atom feed
From: Alan Modra <amodra@bigpond.net.au>
To: Mark Kettenis <kettenis@gnu.org>
Cc: binutils@sources.redhat.com, gdb@sources.redhat.com
Subject: Re: elf.c assign_file_positions_for_segments
Date: Fri, 24 Sep 2004 03:09:00 -0000	[thread overview]
Message-ID: <20040924030920.GG30257@bubble.modra.org> (raw)
In-Reply-To: <20040924001757.GF30257@bubble.modra.org>

On Fri, Sep 24, 2004 at 09:47:57AM +0930, Alan Modra wrote:
> On Fri, Sep 24, 2004 at 09:12:22AM +0930, Alan Modra wrote:
> > On Thu, Sep 23, 2004 at 05:51:17PM +0200, Mark Kettenis wrote:
> > > I'm not sure where to fix this.
> > 
> > I didn't think about gdb using bfd to generate core files.  Clearly, I
> > need to fix my breakage of assign_file_positions_for_segments.
> 
> While waiting for gdb to build, I took a look at gcore.c.  For read-only
> sections, I see you clear SEC_LOAD but leave SEC_HAS_CONTENTS set.
> This is very likely why you're getting filesz non-zero for these
> sections.  The new code consistently checks both SEC_LOAD and
> SEC_HAS_CONTENTS whereas the old code just checked SEC_HAS_CONTENTS in
> one place.
> 
> I'll take a good look at exactly why the SEC_HAS_CONTENTS check is
> needed, ie. whether the following comment reflects current reality.
> /* We check SEC_HAS_CONTENTS here because if NOLOAD is used in a linker
>    script we may have a section with SEC_LOAD clear but which is
>    supposed to have contents.  */
> 
> If we really don't need the SEC_HAS_CONTENTS test, then I'll take it out
> and gdb gcore should be OK, otherwise I might ask you to clear
> SEC_HAS_CONTENTS in gdb.

I think it likely that the SEC_HAS_CONTENTS test is just a hack to work
around another problem.  I'm applying the following to go back to the
old behaviour.

You might like to clear SEC_HAS_CONTENTS in gdb too, as it will result
in needless file space being allocated.

	* elf.c (IS_LOADED): Delete.
	(assign_file_positions_for_segments): Just test SEC_LOAD instead.
	Restore SEC_HAS_CONTENTS test to the one place it was used prior
	to 2004-09-22.

Index: bfd/elf.c
===================================================================
RCS file: /cvs/src/src/bfd/elf.c,v
retrieving revision 1.246
diff -u -p -r1.246 elf.c
--- bfd/elf.c	22 Sep 2004 06:45:38 -0000	1.246
+++ bfd/elf.c	24 Sep 2004 02:59:52 -0000
@@ -3787,12 +3787,6 @@ vma_page_aligned_bias (bfd_vma vma, ufil
   return ((vma - off) % maxpagesize);
 }
 
-/* We check SEC_HAS_CONTENTS here because if NOLOAD is used in a linker
-   script we may have a section with SEC_LOAD clear but which is
-   supposed to have contents.  */
-#define IS_LOADED(FLAGS) \
-  (((FLAGS) & SEC_LOAD) != 0 || ((FLAGS) & SEC_HAS_CONTENTS) != 0)
-
 /* Assign file positions to the sections based on the mapping from
    sections to segments.  This function also sets up some fields in
    the file header, and writes out the program headers.  */
@@ -3959,7 +3953,7 @@ assign_file_positions_for_segments (bfd 
 		 .tbss, we need to look at the next section to decide
 		 whether the segment has any loadable sections.  */
 	      i = 0;
-	      while (!IS_LOADED (m->sections[i]->flags))
+	      while ((m->sections[i]->flags & SEC_LOAD) == 0)
 		{
 		  if ((m->sections[i]->flags & SEC_THREAD_LOCAL) == 0
 		      || ++i >= m->count)
@@ -4107,7 +4101,7 @@ assign_file_positions_for_segments (bfd 
 	    {
 	      bfd_signed_vma adjust;
 
-	      if (IS_LOADED (flags))
+	      if ((flags & SEC_LOAD) != 0)
 		{
 		  adjust = sec->lma - (p->p_paddr + p->p_filesz);
 		  if (adjust < 0)
@@ -4164,11 +4158,26 @@ assign_file_positions_for_segments (bfd 
 	      if (p->p_type == PT_LOAD)
 		{
 		  sec->filepos = off;
-		  if (IS_LOADED (flags))
+		  /* FIXME: The SEC_HAS_CONTENTS test here dates back to
+		     1997, and the exact reason for it isn't clear.  One
+		     plausible explanation is that it is to work around
+		     a problem we have with linker scripts using data
+		     statements in NOLOAD sections.  I don't think it
+		     makes a great deal of sense to have such a section
+		     assigned to a PT_LOAD segment, but apparently
+		     people do this.  The data statement results in a
+		     bfd_data_link_order being built, and these need
+		     section contents to write into.  Eventually, we get
+		     to _bfd_elf_write_object_contents which writes any
+		     section with contents to the output.  Make room
+		     here for the write, so that following segments are
+		     not trashed.  */
+		  if ((flags & SEC_LOAD) != 0
+		      || (flags & SEC_HAS_CONTENTS) != 0)
 		    off += sec->size;
 		}
 
-	      if (IS_LOADED (flags))
+	      if ((flags & SEC_LOAD) != 0)
 		{
 		  p->p_filesz += sec->size;
 		  p->p_memsz += sec->size;


-- 
Alan Modra
IBM OzLabs - Linux Technology Centre


  reply	other threads:[~2004-09-24  3:09 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-09-23 15:51 Mark Kettenis
2004-09-23 23:42 ` Alan Modra
2004-09-24  0:18   ` Alan Modra
2004-09-24  3:09     ` Alan Modra [this message]
2004-09-24  6:36       ` Mark Kettenis
2004-09-28 16:15 Michael Chastain

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=20040924030920.GG30257@bubble.modra.org \
    --to=amodra@bigpond.net.au \
    --cc=binutils@sources.redhat.com \
    --cc=gdb@sources.redhat.com \
    --cc=kettenis@gnu.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