- http://sources.redhat.com/bugzilla/show_bug.cgi?id=338

Changed files:
    binutils-pr338.patch -> 1.1

diff --git a/binutils-pr338.patch b/binutils-pr338.patch
new file mode 100644 (file)
index 0000000..41ceabf
--- /dev/null
+++ b/binutils-pr338.patch
@@ -0,0 +1,40 @@
+2004-08-18  Alan Modra  <amodra@bigpond.net.au>
+
+       PR 338
+       * elflink.c (bfd_elf_record_link_assignment): Add comment about
+       changing bfd_link_hash_undefined to bfd_link_hash_new.
+
+2004-08-18  Alan Modra  <amodra@bigpond.net.au>
+
+       PR 338
+       * ldexp.c (fold_name): Don't call bfd_link_add_undef if the symbol
+       was already on the undefs list.
+
+--- src/bfd/elflink.c  2004/08/17 08:51:07     1.96
++++ src/bfd/elflink.c  2004/08/18 02:45:42     1.97
+@@ -434,7 +434,12 @@
+ 
+   /* Since we're defining the symbol, don't let it seem to have not
+      been defined.  record_dynamic_symbol and size_dynamic_sections
+-     may depend on this.  */
++     may depend on this.
++     ??? Changing bfd_link_hash_undefined to bfd_link_hash_new (or
++     to bfd_link_hash_undefweak, see linker.c:link_action) runs the risk
++     of some later symbol manipulation setting the symbol back to
++     bfd_link_hash_undefined, and the linker trying to add the symbol to
++     the undefs list twice.  */
+   if (h->root.type == bfd_link_hash_undefweak
+       || h->root.type == bfd_link_hash_undefined)
+     h->root.type = bfd_link_hash_new;
+--- src/ld/ldexp.c     2004/06/24 04:46:27     1.31
++++ src/ld/ldexp.c     2004/08/18 02:45:43     1.32
+@@ -576,7 +576,8 @@
+           {
+             h->type = bfd_link_hash_undefined;
+             h->u.undef.abfd = NULL;
+-            bfd_link_add_undef (link_info.hash, h);
++            if (h->und_next == NULL)
++              bfd_link_add_undef (link_info.hash, h);
+           }
+       }
+       break;