From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25486 invoked by alias); 26 Feb 2011 00:47:13 -0000 Received: (qmail 25478 invoked by uid 22791); 26 Feb 2011 00:47:13 -0000 X-SWARE-Spam-Status: No, hits=-2.2 required=5.0 tests=AWL,BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW X-Spam-Check-By: sourceware.org Received: from mail-ww0-f43.google.com (HELO mail-ww0-f43.google.com) (74.125.82.43) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Sat, 26 Feb 2011 00:47:09 +0000 Received: by mail-ww0-f43.google.com with SMTP id 15so2101428wwe.12 for ; Fri, 25 Feb 2011 16:47:08 -0800 (PST) Received: by 10.227.153.204 with SMTP id l12mr2720038wbw.81.1298681228796; Fri, 25 Feb 2011 16:47:08 -0800 (PST) Received: from [192.168.2.99] (cpc2-cmbg8-0-0-cust61.5-4.cable.virginmedia.com [82.6.108.62]) by mx.google.com with ESMTPS id o6sm1025166wbo.21.2011.02.25.16.47.07 (version=SSLv3 cipher=OTHER); Fri, 25 Feb 2011 16:47:08 -0800 (PST) Message-ID: <4D684D79.9090708@gmail.com> Date: Sat, 26 Feb 2011 00:47:00 -0000 From: Dave Korn User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: "binutils@sourceware.org" Subject: [6/6][PATCH] Respect symbol wrappers when computing symbol resolutions. References: <4D684CB8.6020106@gmail.com> <4D684D00.70803@gmail.com> In-Reply-To: <4D684D00.70803@gmail.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 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-02/txt/msg00334.txt.bz2 Hi list, I found this running the GCC testsuite, where on cygwin we use ld wrappers to allow replacement of libstdc++ new/delete operators. ld/ChangeLog: 2011-02-24 Dave Korn <... * plugin.c (get_symbols): Use wrapped lookup for undefined symbols. I'd like it if someone can confirm that I've correctly interpreted the comment that precedes the definition of bfd_wrapped_link_hash_lookup, about how it should "only be used for references to an undefined symbol, not for definitions of a symbol"; I took that to mean that I should key off the initial state of defined-ness of the symbol passed from the plugin and call either a wrapped or unwrapped lookup accordingly, but possibly since we're asking about the resolution of a symbol, it would make as much sense to always treat this as if we were looking up an undefined reference and simply always call the wrapped lookup? cheers, DaveK