The problem with linkonce sections in ELF

Ian Lance Taylor ian@zembu.com
Sun Feb 6 13:20:00 GMT 2000


   Date: Thu, 3 Feb 2000 20:45:49 -0800
   From: "H . J . Lu" <hjl@lucon.org>

   The probelm is the output .rel.text section consists of .rel.text,
   .rel.text.* and .rel.gnu.linkonce.t*. All the them are generated
   by the linker. With -Bsymbolic, elf_i386_size_dynamic_sections calls

	   if (info->shared && info->symbolic)
	     elf_i386_link_hash_traverse (elf_i386_hash_table (info),
					  elf_i386_discard_copies,
					  (PTR) NULL);

   It is very possible that one of the .rel.gnu.linkonce.t* relocations
   created by the linker will be striped by _bfd_strip_section_from_output.
   When it happens, the output .rel.text section will be removed although
   there are other .rel.text, .rel.text.* and .rel.gnu.linkonce.t* left.

   I think _bfd_strip_section_from_output has to be 100% sure that
   all linker generated relocations are striped before it removes
   the output relocation section.

Thanks for the analysis and the test case.

I don't know why _bfd_strip_section_from_output looks at link_order
information at all.  In all the calls that I can see, the link_order
information has not yet been set up.  Now I see why you were trying to
add link_order information earlier.

But that doesn't make sense.  The link_order information is only
meaningful after section sizes are known.  Section sizes are not known
when size_dynamic_section is called, and size_dynamic_section
generates all the current calls to strip_section_from_output.

The appended patch fixes the problem for me.  You also have to
regenerate bfd-in2.h, and patch all the calls to size_dynamic_sections
to pass the extra argument.  This is not very efficient; I don't know
how often strip_section_from_output is called in real cases.

Ian

Index: section.c
===================================================================
RCS file: /cvs/binutils/binutils/bfd/section.c,v
retrieving revision 1.10
diff -u -r1.10 section.c
--- section.c	2000/01/13 22:10:36	1.10
+++ section.c	2000/02/06 21:14:48
@@ -1100,20 +1100,28 @@
 
 SYNOPSIS
 	void _bfd_strip_section_from_output
-	(asection *section);
+	(struct bfd_link_info *info, asection *section);
 
 DESCRIPTION
-	Remove @var{section} from the output.  If the output section becomes
-	empty, remove it from the output bfd.
+	Remove @var{section} from the output.  If the output section
+	becomes empty, remove it from the output bfd.  @var{info} may
+	be NULL; if it is not, it is used to decide whether the output
+	section is empty.
 */
 void
-_bfd_strip_section_from_output (s)
+_bfd_strip_section_from_output (info, s)
+     struct bfd_link_info *info;
      asection *s;
 {
   asection **spp, *os;
   struct bfd_link_order *p, *pp;
+  boolean keep_os;
 
-  /* Excise the input section from the link order.  */
+  /* Excise the input section from the link order.
+
+     FIXME: For all calls that I can see to this function, the link
+     orders have not yet been set up.  So why are we checking them? --
+     Ian */
   os = s->output_section;
   for (p = os->link_order_head, pp = NULL; p != NULL; pp = p, p = p->next)
     if (p->type == bfd_indirect_link_order
@@ -1128,10 +1136,30 @@
 	break;
       }
 
+  keep_os = os->link_order_head != NULL;
+
+  if (! keep_os && info != NULL)
+    {
+      bfd *abfd;
+      for (abfd = info->input_bfds; abfd != NULL; abfd = abfd->link_next)
+	{
+	  asection *is;
+	  for (is = abfd->sections; is != NULL; is = is->next)
+	    {
+	      if (is->output_section == os)
+		break;
+	    }
+	  if (is != NULL)
+	    break;
+	}
+      if (abfd != NULL)
+	keep_os = true;
+    }
+
   /* If the output section is empty, remove it too.  Careful about sections
      that have been discarded in the link script -- they are mapped to 
      bfd_abs_section, which has no owner.  */
-  if (!os->link_order_head && os->owner)
+  if (!keep_os && os->owner != NULL)
     {
       for (spp = &os->owner->sections; *spp; spp = &(*spp)->next)
 	if (*spp == os)


More information about the Binutils mailing list