Re: [RFC] unify dynamic_symbol_p implementations

[Bob Wilson <bwilson@tensilica.com>]

I think the "ignore_protected" argument should be 0 for the Xtensa port.  A 
separate relocation (R_XTENSA_32) is used when taking the address of a 
function than when calling it (R_XTENSA_PLT), so there shouldn't be an issue 
with incorrectly comparing the PLT addresses instead of the function 
addresses.  Unless I'm missing something here, you shouldn't have to "assume 
the worst".

> --- elf32-xtensa.c      10 Jul 2003 19:01:47 -0000      1.5
> +++ elf32-xtensa.c      16 Jul 2003 23:35:31 -0000
> @@ -1838,38 +1838,9 @@ xtensa_elf_dynamic_symbol_p (info, h)
> 
[ stuff deleted from here ]
> +  /* ??? What, if anything, needs to happen wrt STV_PROTECTED and PLT
> +     entries?  For now assume the worst.  */
> +  return _bfd_elf_dynamic_symbol_p (h, info, 1);
>  }


Another very minor point is that I find your new comment below confusing.  It 
describes a difference from the generic version but then goes on to use the 
generic version.  I think you're referring to passing 0 for the 
"ignore_protected" argument, right?

--- elf64-alpha.c       4 Jul 2003 13:53:37 -0000       1.101
+++ elf64-alpha.c       16 Jul 2003 23:35:31 -0000
[ chunk deleted ]
@@ -269,49 +269,17 @@ struct alpha_elf_link_hash_table
 #define alpha_elf_sym_hashes(abfd) \
   ((struct alpha_elf_link_hash_entry **)elf_sym_hashes(abfd))
 
-/* Should we do dynamic things to this symbol?  */
+/* Should we do dynamic things to this symbol?  This differs from the 
+   generic version in that we never need to consider function pointer
+   equality wrt PLT entries -- we don't create a PLT entry if a symbol's
+   address is ever taken.  */