Re: Your change to ldlang.c

[Ian Lance Taylor <ian@zembu.com>]

   From: Mark Mitchell <mark@codesourcery.com>
   Date: Thu, 01 Jul 1999 20:30:04 -0700

       Ian> My main concern was that it would mess up relocations.  If an
       Ian> input section disappears, relocations against symbols in that
       Ian> section need to be adjusted to use different symbols, and
       Ian> relocations for that section need to disappear.  I doubt the
       Ian> backends do either of these correctly.

   I see.  Of course, in this case, there are no relocations against the
   section.  

   I guess I don't see why your solution is really any better.  On the
   one hand, we may have bogus relocations.  On the other, we've violated
   the SEC_LINK_ONCE semantics, especially for fixed-sized sections like
   .reginfo. 

It's not clear to me what SEC_LINK_ONCE semantics are in the case of a
relocateable link.  My first reaction when I noticed this was actually
that a relocateable link should keep all the sections, and that the
current behaviour was simply a bug.

SEC_LINK_ONCE was originally meant to be something along the lines of
PE COMDAT sections.  Can anybody check what the Microsoft linker does
when doing a relocateable link with multiple COMDAT sections?

   I guess I'm thinking we should undo your change, and then attack the
   problem of making the back-ends handle the relocations correctly.
   That should not be *that* hard.

It's not trivial, actually, when you consider relocations against
local symbols in a linkonce section.  In some cases those relocations
can simply be removed, as in a debugging section, but in other cases
you need to actually modify the relocation to a different section.  I
think every backend would have to be modified.

       Ian> We could go back to letting the emultempl file handle the
       Ian> .reginfo sections for MIPS files when doing a relocateable
       Ian> link, I suppose.  Does anybody have a better suggestion?

   I don't know what you mean by this suggestion.  I guess I'm too new to
   binutils-land.  Could you elaborate on the emultempl file solution?

Until quite recently (February 1999), .reginfo sections were not
marked as LINK_ONCE, and they were instead handled in the emultempl
file.  The special handling was removed by this patch:

Wed Feb 17 12:10:06 1999  Stan Cox  <scox@cygnus.com>

	* mpw-elfmips.c (gldelf32ebmip_before_allocation): Remove special
	.reginfo section handling. 
	* emultempl/elf32.em (gld${EMULATION_NAME}_before_allocation): Likewise.
	* emulparams/elf32elmip.sh (INITIAL_READONLY_SECTIONS): Removed
	* emulparams/elf32ebmip.sh (INITIAL_READONLY_SECTIONS): Removed

Index: elf32.em
===================================================================
RCS file: /cvs/cvsfiles/devo/ld/emultempl/elf32.em,v
retrieving revision 1.57
retrieving revision 1.58
diff -u -r1.57 -r1.58
--- elf32.em	1998/09/20 04:16:36	1.57
+++ elf32.em	1999/02/17 19:58:05	1.58
@@ -762,37 +762,6 @@
 	s->_raw_size = 0;
       }
   }
-
-#if defined (TARGET_IS_elf32bmip) || defined (TARGET_IS_elf32lmip)
-  /* For MIPS ELF the .reginfo section requires special handling.
-     Each input section is 24 bytes, and the final output section must
-     also be 24 bytes.  We handle this by clobbering all but the first
-     input section size to 0.  The .reginfo section is handled
-     specially by the backend code anyhow.  */
-  {
-    boolean found = false;
-    LANG_FOR_EACH_INPUT_STATEMENT (is)
-      {
-	asection *s;
-
-	if (is->just_syms_flag)
-	  continue;
-
-	s = bfd_get_section_by_name (is->the_bfd, ".reginfo");
-	if (s == NULL)
-	  continue;
-
-	if (! found)
-	  {
-	    found = true;
-	    continue;
-	  }
-
-	s->_raw_size = 0;
-	s->_cooked_size = 0;
-      }
-  }
-#endif
 }
 
 /* This is called by the before_allocation routine via