[PATCH] SEGV whilst placing sections

[Mark Shinwell]

Alan Modra wrote:
 > On Tue, Jun 20, 2006 at 03:08:52PM +0100, Mark Shinwell wrote:
 >> In this case, the "after" parameter to lang_insert_orphan () corresponds
 >> to the .rodata section, the last in the linked list of "asection"s.
 >> The upshot is that place->section points at the "next" entry of the final
 >> section in the list, .rodata.  This "next" pointer is NULL, so "as" ends up
 >> NULL, and we fault when "as->prev" is computed.
 >
 >> +      if (!as)
 >> +        {
 >> +          /* Put the section at the end of the list.  */
 >
 > Isn't the section already at the end of the list in this case?

Your fix works, so presumably it is, but I'm still slightly in the dark
as to why :-)  Am I right in thinking that tracing the "prev" and "next"
pointers starting at "after->bfd_section" is traversing the list of all
sections that we have to place, whereas the section_list_remove and
section_list_append here:

 >> +	  /* Unlink the section.  */
 >> +	  bfd_section_list_remove (output_bfd, snew);
 >> +
 >> +	  /* Now tack it back on in the right place.  */
 >> +	  bfd_section_list_append (output_bfd, snew);

were actually affecting a different list of sections?  (Since tracing
from after->bfd_section shows that .rodata is the last in the list
there.)

Is the attached ok?

Mark

--

2006-06-20  Mark Shinwell  <shinwell@codesourcery.com>

	* ldlang.c (lang_insert_orphan): Correctly handle the case where
	the section is to end up after the section currently at the end
	of the list in output_bfd.
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: section-placing.patch
URL: <https://sourceware.org/pipermail/binutils/attachments/20060620/985c9094/attachment.ksh>