From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 29226 invoked by alias); 20 Jul 2003 15:26:47 -0000 Mailing-List: contact binutils-help@sources.redhat.com; run by ezmlm Precedence: bulk List-Subscribe: List-Archive: List-Post: List-Help: , Sender: binutils-owner@sources.redhat.com Received: (qmail 29219 invoked from network); 20 Jul 2003 15:26:47 -0000 Received: from unknown (HELO rwcrmhc11.comcast.net) (204.127.198.35) by sources.redhat.com with SMTP; 20 Jul 2003 15:26:47 -0000 Received: from lucon.org ([12.234.88.5]) by comcast.net (rwcrmhc11) with ESMTP id <2003072015264601300h11die>; Sun, 20 Jul 2003 15:26:46 +0000 Received: by lucon.org (Postfix, from userid 1000) id AA9F62C4EB; Sun, 20 Jul 2003 15:26:43 +0000 (UTC) Date: Sun, 20 Jul 2003 15:26:00 -0000 From: "H. J. Lu" To: Richard Henderson , binutils@sources.redhat.com Subject: Re: [RFC] unify dynamic_symbol_p implementations Message-ID: <20030720152643.GA26257@lucon.org> References: <200307181202.40668.bwilson@tensilica.com> <20030718220239.GE5270@redhat.com> <20030718220412.GA23962@nevyn.them.org> <200307181516.12627.bwilson@tensilica.com> <20030718222150.GF5270@redhat.com> <20030719024642.GA1188@lucon.org> <20030719041330.GA3732@lucon.org> <20030719055725.GF27145@bubble.sa.bigpond.net.au> <20030719062106.GA5320@lucon.org> <20030720151351.GH27145@bubble.sa.bigpond.net.au> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20030720151351.GH27145@bubble.sa.bigpond.net.au> User-Agent: Mutt/1.4.1i X-SW-Source: 2003-07/txt/msg00376.txt.bz2 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.