This is the mail archive of the binutils@sourceware.org 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]

[commit] Restore .gnu.linkonce.r. g++-3.4 linking


On Sat, 20 Dec 2008 12:00:29 +0100, Alan Modra wrote:
> On Wed, Dec 17, 2008 at 09:49:22PM +0100, Jan Kratochvil wrote:
> > Re: [patch] Restore .gnu.linkonce.r. g++-3.4 linking
> > http://sourceware.org/ml/binutils/2008-11/msg00195.html
> > followup on: http://sourceware.org/ml/binutils/2008-10/threads.html#00200
> 
> Apologies for the delay.  The patch is OK, but I'm fairly sure you
> do not need the last strcmp due to the fact that already_linked_list
> only contains sections that will match.  Please test with that change
> and commit.

Checked in.  Adjusted the comment in ld/testsuite/ld-elf/linkoncerdiff2.s, I
hope it is OK.  Testsuite results - PASSes except:

hppa64-hp-hpux11.23
ld-elf/linkoncerdiff2.s:2: Error: junk at end of line, first unrecognized character is `1'
local labels `1' and `2' FAIL there; .L* also fail for some targets

Other FAILs are the same as for other existing testcases ld-elf/linkonce*:

mips-sgi-irix5
./ld-new: unrecognised emulation mode: elf32bsmip

mmix-elf
ld-elf/linkoncerdiff1.s:1: Error: junk at end of line, first unrecognized character is `,'

mn10200-elf
./ld-new: unrecognised emulation mode: mn10200

mn10300-elf
./ld-new: unrecognised emulation mode: mn10300

pj-elf
./ld-new: cannot represent machine `pj'

shl-unknown-netbsdelf1.6T
./ld-new: tmpdir/dump0.o: compiled for a big endian system and target is little endian
./ld-new: tmpdir/dump0.o: uses instructions which are incompatible with instructions used in previous modules
./ld-new: failed to merge target specific data of file tmpdir/dump0.o
./ld-new: tmpdir/dump1.o: compiled for a big endian system and target is little endian
./ld-new: tmpdir/dump1.o: uses instructions which are incompatible with instructions used in previous modules
./ld-new: failed to merge target specific data of file tmpdir/dump1.o

v850-elf
./ld-new: unrecognised emulation mode: v850


Thanks,
Jan


http://sourceware.org/ml/binutils-cvs/2009-01/msg00060.html

bfd/
2009-01-11  Jan Kratochvil  <jan.kratochvil@redhat.com>

	* elflink.c (_bfd_elf_section_already_linked): Handle g++-3.4
	relocations in `.gnu.linkonce.r.*' referencing its `.gnu.linkonce.t.*'.

ld/testsuite/
2009-01-11  Jan Kratochvil  <jan.kratochvil@redhat.com>

	* ld-elf/linkoncerdiff.d, ld-elf/linkoncerdiff1.s,
	ld-elf/linkoncerdiff2.s: New.

--- src/bfd/elflink.c	2009/01/03 16:19:52	1.323
+++ src/bfd/elflink.c	2009/01/11 21:09:46	1.324
@@ -12281,6 +12281,28 @@
 	    }
 	}
 
+  /* Do not complain on unresolved relocations in `.gnu.linkonce.r.F'
+     referencing its discarded `.gnu.linkonce.t.F' counterpart - g++-3.4
+     specific as g++-4.x is using COMDAT groups (without the `.gnu.linkonce'
+     prefix) instead.  `.gnu.linkonce.r.*' were the `.rodata' part of its
+     matching `.gnu.linkonce.t.*'.  If `.gnu.linkonce.r.F' is not discarded
+     but its `.gnu.linkonce.t.F' is discarded means we chose one-only
+     `.gnu.linkonce.t.F' section from a different bfd not requiring any
+     `.gnu.linkonce.r.F'.  Thus `.gnu.linkonce.r.F' should be discarded.
+     The reverse order cannot happen as there is never a bfd with only the
+     `.gnu.linkonce.r.F' section.  The order of sections in a bfd does not
+     matter as here were are looking only for cross-bfd sections.  */
+
+  if ((flags & SEC_GROUP) == 0 && CONST_STRNEQ (name, ".gnu.linkonce.r."))
+    for (l = already_linked_list->entry; l != NULL; l = l->next)
+      if ((l->sec->flags & SEC_GROUP) == 0
+	  && CONST_STRNEQ (l->sec->name, ".gnu.linkonce.t."))
+	{
+	  if (abfd != l->sec->owner)
+	    sec->output_section = bfd_abs_section_ptr;
+	  break;
+	}
+
   /* This is the first section with this name.  Record it.  */
   if (! bfd_section_already_linked_table_insert (already_linked_list, sec))
     info->callbacks->einfo (_("%F%P: already_linked_table: %E"));
--- src/ld/testsuite/ld-elf/linkoncerdiff.d
+++ src/ld/testsuite/ld-elf/linkoncerdiff.d	2009-01-11 21:13:01.496499000 +0000
@@ -0,0 +1,6 @@
+#source: linkoncerdiff1.s
+#source: linkoncerdiff2.s
+#ld: -r
+#readelf: -r
+There are no relocations in this file.
+#pass
--- src/ld/testsuite/ld-elf/linkoncerdiff1.s
+++ src/ld/testsuite/ld-elf/linkoncerdiff1.s	2009-01-11 21:13:02.821259000 +0000
@@ -0,0 +1,7 @@
+	.section	.gnu.linkonce.t.foo, "a", %progbits
+	.globl	symfoo
+symfoo:
+
+	.section	.gnu.linkonce.t.bar, "a", %progbits
+	.globl	symbar
+symbar:
--- src/ld/testsuite/ld-elf/linkoncerdiff2.s
+++ src/ld/testsuite/ld-elf/linkoncerdiff2.s	2009-01-11 21:13:03.982208000 +0000
@@ -0,0 +1,22 @@
+	.section	.gnu.linkonce.t.foo, "a", %progbits
+1:
+	.globl	symfoo
+symfoo:
+	.long	0
+
+	.section	.gnu.linkonce.t.bar, "a", %progbits
+2:
+	.globl	symbar
+symbar:
+	.long	0
+
+	.section	.gnu.linkonce.r.foo, "a", %progbits
+	.long	1b
+	.long	symfoo
+/* ld currently incorrectly silently discards this relocation.  Just such
+   relocations are never produced by g++-3.4 so this suppressed error message
+   is not a problem:
+   #error: `.gnu.linkonce.t.bar' referenced in section `.gnu.linkonce.r.foo' of tmpdir/dump1.o: defined in discarded section `.gnu.linkonce.t.bar' of tmpdir/dump1.o
+   */
+	.long	2b
+	.long	symbar


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