This is the mail archive of the binutils@sources.redhat.com mailing list for the binutils project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

frv ld: don't warn for relocs to discarded linkonce section symbols


When a relocation references a linkonce section symbol that was
discarded, the relocation is modified such that its symbol index is
zero long after we sized dynamic sections, right before we try to emit
the dynamic relocation.

Unfortunately, the code I (not really) recently added to catch cases
of emitting too many dynamic relocations for a symbol caught such an
inconsistency while building libstdc++.so for frv-uclinux.

I don't see a clean way to address this problem.  We don't know the
section is going to be discarded in check_relocs, where we initially
collect the information.  In size_dynamic_sections, we can't get to
the local symbol/section table of the bfd to tell whether the section
was discarded either.  Then, in relocate_section, the relocation was
already modified and we can't get back the information we need to tell
which entry we should get the information from.  So I'm just punting
at it and disabling the warning at this point.  If it turns out that
we emit a different number of dynamic relocations than initially
estimated, we'll still get a warning.

Ideally, we'd omit the dynamic relocation (or rofixup entry) entirely,
but especially for rofixups, we really can't do that, because the
sizes of the sections have already been determined, and symbols
pointing to the beginning and end of .rofixup have already been
defined.  We could omit the dynamic relocations, but the number of
dynamic relocations would have already been set as well, so we don't
gain anything.

Anyhow...  Here's the patch.  Ok?

Index: bfd/ChangeLog
from  Alexandre Oliva  <aoliva@redhat.com>

	* elf32-frv.c (_frvfdpic_add_dyn_reloc): Don't warn when we get
	a zero symndx for which we hadn't accounted a dynamic relocation.
	(_frvfdpic_add_rofixup): Likewise.

Index: bfd/elf32-frv.c
===================================================================
RCS file: /cvs/src/src/bfd/elf32-frv.c,v
retrieving revision 1.22
diff -u -p -r1.22 elf32-frv.c
--- bfd/elf32-frv.c 6 May 2004 02:46:29 -0000 1.22
+++ bfd/elf32-frv.c 6 May 2004 06:31:53 -0000
@@ -939,8 +939,18 @@ _frvfdpic_add_dyn_reloc (bfd *output_bfd
 			    sreloc->contents + reloc_offset);
   sreloc->reloc_count++;
 
-  BFD_ASSERT (entry->dynrelocs > 0);
-  entry->dynrelocs--;
+  /* If the entry's index is zero, this relocation was probably to a
+     linkonce section that got discarded.  We reserved a dynamic
+     relocation, but it was for another entry than the one we got at
+     the time of emitting the relocation.  Unfortunately there's no
+     simple way for us to catch this situation, since the relocation
+     is cleared right before calling relocate_section, at which point
+     we no longer know what the relocation used to point to.  */
+  if (entry->symndx)
+    {
+      BFD_ASSERT (entry->dynrelocs > 0);
+      entry->dynrelocs--;
+    }
 
   return reloc_offset;
 }
@@ -964,8 +974,10 @@ _frvfdpic_add_rofixup (bfd *output_bfd, 
     }
   rofixup->reloc_count++;
 
-  if (entry)
+  if (entry && entry->symndx)
     {
+      /* See discussion about symndx == 0 in _frvfdpic_add_dyn_reloc
+	 above.  */
       BFD_ASSERT (entry->fixups > 0);
       entry->fixups--;
     }
-- 
Alexandre Oliva             http://www.ic.unicamp.br/~oliva/
Red Hat Compiler Engineer   aoliva@{redhat.com, gcc.gnu.org}
Free Software Evangelist  oliva@{lsd.ic.unicamp.br, gnu.org}

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]