Re: [RFC] unify dynamic_symbol_p implementations

["H. J. Lu" <hjl at lucon dot org>]

On Mon, Jul 21, 2003 at 12:43:51AM +0930, Alan Modra wrote:
> On Fri, Jul 18, 2003 at 11:21:06PM -0700, H. J. Lu wrote:
> > That is not the problem. _bfd_elf_dynamic_symbol_p came from
> > elfxx-ia64.c, which isn't symmetric with SYMBOL_REFERENCES_LOCAL.
> > I don't know how we can get it both ways.
> 
> Yes, I see I agreed with Richard's patch too quickly..  The problem is
> that SYMBOL_REFERENCES_LOCAL and SYMBOL_CALLS_LOCAL as used by ppc,
> ppc64, x86, and x86_64 should only return true if we have a local
> definition.  Causes failures in ld tests of visibility (hidden_undef).
> I do like the idea of a predicate function though.
> 
> 	* elf-bfd.h (SYMBOL_REFERENCES_LOCAL, SYMBOL_CALLS_LOCAL): Use..
> 	(_bfd_elf_symbol_refs_local_p): ..this.  Declare.
> 	* elflink.c (_bfd_elf_symbol_refs_local_p): New function.
> 	* elf32-i386.c (elf_i386_relocate_section): Remove h NULL test
> 	now done in _bfd_elf_symbol_refs_local_p.
> 	* elf32-ppc.c (ppc_elf_relocate_section): Likewise.
> 	* elf64-ppc.c (ppc64_elf_relocate_section): Likewise.
> 	* elf64-x86-64.c (elf64_x86_64_relocate_section): Likewise.
> 
> One interesting place that this differs from (the inverse of) Richard's
> function is in the treatment of weak and undefweak dynamic syms.  I
> suspect I should allow a weak dynamic sym in an executable to be
> overridden, even if we don't find a strong sym in a shared lib supplied
> at link time.  Comments?

Weak defined symbols are purely for link time and only meaningful for
relocatable inputs. Any defintions from shared libraries are ignored
if there is a defintion in relocatable inputs, weak or strong. As runtime,
they are as good as strong. I added some testcases for them. Please do
"make check" on x86 with glibc 2.3 from CVS. If you do not get any
weak symbol check failures, you should be ok.


H.J.