From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27327 invoked by alias); 8 Jun 2011 00:36:02 -0000 Received: (qmail 27277 invoked by uid 22791); 8 Jun 2011 00:36:01 -0000 X-SWARE-Spam-Status: No, hits=-2.4 required=5.0 tests=AWL,BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,RFC_ABUSE_POST X-Spam-Check-By: sourceware.org Received: from mail-pv0-f169.google.com (HELO mail-pv0-f169.google.com) (74.125.83.169) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Wed, 08 Jun 2011 00:35:47 +0000 Received: by pvc12 with SMTP id 12so21088pvc.0 for ; Tue, 07 Jun 2011 17:35:47 -0700 (PDT) Received: by 10.68.65.75 with SMTP id v11mr499778pbs.56.1307493346951; Tue, 07 Jun 2011 17:35:46 -0700 (PDT) Received: from bubble.grove.modra.org ([115.187.252.19]) by mx.google.com with ESMTPS id p5sm23045pbk.36.2011.06.07.17.35.44 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 07 Jun 2011 17:35:46 -0700 (PDT) Received: by bubble.grove.modra.org (Postfix, from userid 1000) id D8FA0170C1B4; Wed, 8 Jun 2011 10:05:40 +0930 (CST) Date: Wed, 08 Jun 2011 00:36:00 -0000 From: Alan Modra To: Roland McGrath Cc: bug-binutils@gnu.org, binutils@sourceware.org Subject: Re: .gnu.warning.foo interferes with archive-member rules Message-ID: <20110608003540.GC4172@bubble.grove.modra.org> Mail-Followup-To: Roland McGrath , bug-binutils@gnu.org, binutils@sourceware.org References: <20110607090830.GA4172@bubble.grove.modra.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) X-IsSubscribed: yes Mailing-List: contact binutils-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: binutils-owner@sourceware.org X-SW-Source: 2011-06/txt/msg00077.txt.bz2 On Tue, Jun 07, 2011 at 09:50:18AM -0700, Roland McGrath wrote: > Thanks! I don't understand your changes at all off hand, and I strongly > suspected that the patch I tried was too simple-minded to be right. Setting "follow" true for the elf_link_hash_lookup calls in _bfd_elf_archive_symbol_lookup means we get to the real symbol in the elf_link_add_archive_symbols loop you were patching. We want that because elf_link_add_archive_symbols needs to make a decision depending on whether the symbol is defined or not, and specially treat commons. Indirect and warning syms can point to any other sym type. The lang_one_common change is needed in any function called by bfd_link_hash_traverse. When warning symbols are created, they replace the "real" entry in the hash table, so you never get to see the real symbol in a hash traversal. -- Alan Modra Australia Development Lab, IBM