From da6c418a7a479864abc08c9a66517a68ea0e42bb Mon Sep 17 00:00:00 2001 From: =?utf8?q?Pawe=C5=82=20Sikora?= Date: Wed, 18 Aug 2004 22:00:14 +0000 Subject: [PATCH] - http://sources.redhat.com/bugzilla/show_bug.cgi?id=338 Changed files: binutils-pr338.patch -> 1.1 --- binutils-pr338.patch | 40 ++++++++++++++++++++++++++++++++++++++++ 1 file changed, 40 insertions(+) create mode 100644 binutils-pr338.patch diff --git a/binutils-pr338.patch b/binutils-pr338.patch new file mode 100644 index 0000000..41ceabf --- /dev/null +++ b/binutils-pr338.patch @@ -0,0 +1,40 @@ +2004-08-18 Alan Modra + + 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 + + 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; -- 2.44.0