[RFA] Don't warn when using ld --wrap and code in Thumb-state on ARM

[Matthew Gretton-Dann <matthew dot gretton-dann at arm dot com>]

Hi,

The following patch fixes an issue on ARM when compiling '__wrap_*'
functions (for use with ld's --wrap option) in Thumb state.  This fixes
the two failures in ld/testsuite/ld-elf/wrap.exp.  Please can someone
review and approve it.

The issue is that when the linker tries to wrap a function it assumes
the wrapper symbol (__wrap_<symbolname>) has the same symbol type as the
original symbol - STT_FUNC.  However, in this case when the linker
actually sees the definition of the wrapper function it is given the
symbol type STT_ARM_TFUNC.  This inconsistency between symbol types is
considered to be worthy of a warning by elf_link_add_object_symbols
(bfd/elflink.c around line 4347).

However, this change in symbol type is usually allowed for function
symbols - _bfd_elf_merge_symbol indicates this.  But in this case this
hasn't been allowed because the test for both symbols being function
type symbols is done after an early exit for weak symbols.

The fix is to move the test for merging two function symbols, and so
whether to allow a symbol type change earlier in _bfd_elf_merge_symbol.

I have tested this on arm-none-linux-gnueabi, arm-none-elf,
x86_64-none-linux-gnu

Proposed ChangeLog:

2010-03-29  Matthew Gretton-Dann  <matthew.gretton-dann@arm.com>

	* elflink.c (_bfd_elf_merge_symbol): Move test for both 
	symbols being a function earlier.

Thanks,

Matt

-- 
Matthew Gretton-Dann
Principal Engineer - Tools, PD Software
ARM Limited

Index: bfd/elflink.c
===================================================================
RCS file: /cvs/src/src/bfd/elflink.c,v
retrieving revision 1.371
diff -u -p -r1.371 elflink.c
--- bfd/elflink.c	21 Mar 2010 23:26:33 -0000	1.371
+++ bfd/elflink.c	29 Mar 2010 14:12:50 -0000
@@ -1013,6 +1013,22 @@ _bfd_elf_merge_symbol (bfd *abfd,
       break;
     }
 
+  /* NEWFUNC and OLDFUNC indicate whether the new or old symbol,
+     respectively, appear to be a function.  */
+
+  newfunc = (ELF_ST_TYPE (sym->st_info) != STT_NOTYPE
+	     && bed->is_function_type (ELF_ST_TYPE (sym->st_info)));
+
+  oldfunc = (h->type != STT_NOTYPE
+	     && bed->is_function_type (h->type));
+
+  /* Allow changes between different types of function symbol.  This has to
+     be done before any of the early exit tests so that architectures (like
+     ARM) which define an internal function symbol type (for instance 
+     STT_ARM_TFUNC) can update this type in the link hash entry.  */
+  if (newfunc && oldfunc)
+    *type_change_ok = TRUE;
+
   /* In cases involving weak versioned symbols, we may wind up trying
      to merge a symbol with itself.  Catch that here, to avoid the
      confusion that results if we try to override a symbol with
@@ -1048,15 +1064,6 @@ _bfd_elf_merge_symbol (bfd *abfd,
 	    && h->root.type != bfd_link_hash_undefweak
 	    && h->root.type != bfd_link_hash_common);
 
-  /* NEWFUNC and OLDFUNC indicate whether the new or old symbol,
-     respectively, appear to be a function.  */
-
-  newfunc = (ELF_ST_TYPE (sym->st_info) != STT_NOTYPE
-	     && bed->is_function_type (ELF_ST_TYPE (sym->st_info)));
-
-  oldfunc = (h->type != STT_NOTYPE
-	     && bed->is_function_type (h->type));
-
   /* When we try to create a default indirect symbol from the dynamic
      definition with the default version, we skip it if its type and
      the type of existing regular definition mismatch.  We only do it
@@ -1265,10 +1272,6 @@ _bfd_elf_merge_symbol (bfd *abfd,
   if (olddef && newdyn)
     oldweak = FALSE;
 
-  /* Allow changes between different types of function symbol.  */
-  if (newfunc && oldfunc)
-    *type_change_ok = TRUE;
-
   /* It's OK to change the type if either the existing symbol or the
      new symbol is weak.  A type change is also OK if the old symbol
      is undefined and the new symbol is defined.  */