This is the mail archive of the
binutils@sources.redhat.com
mailing list for the binutils project.
Re: [RFC] unify dynamic_symbol_p implementations
- From: Bob Wilson <bwilson at tensilica dot com>
- To: rth at redhat dot com
- Cc: binutils at sources dot redhat dot com
- Date: Fri, 18 Jul 2003 12:02:40 -0700
- Subject: Re: [RFC] unify dynamic_symbol_p implementations
- Organization: Tensilica, Inc.
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. */