From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <binutils-return-70290-listarch-binutils=sources.redhat.com@sourceware.org>
Received: (qmail 5110 invoked by alias); 25 Feb 2011 23:08:31 -0000
Received: (qmail 5095 invoked by uid 22791); 25 Feb 2011 23:08:30 -0000
X-SWARE-Spam-Status: No, hits=-2.3 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-qw0-f41.google.com (HELO mail-qw0-f41.google.com) (209.85.216.41)    by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Fri, 25 Feb 2011 23:08:25 +0000
Received: by qwd7 with SMTP id 7so2068468qwd.0        for <binutils@sourceware.org>; Fri, 25 Feb 2011 15:08:23 -0800 (PST)
MIME-Version: 1.0
Received: by 10.224.28.210 with SMTP id n18mr2566338qac.191.1298675303484; Fri, 25 Feb 2011 15:08:23 -0800 (PST)
Received: by 10.224.61.18 with HTTP; Fri, 25 Feb 2011 15:08:23 -0800 (PST)
In-Reply-To: <4D683105.70307@gmail.com>
References: <20110224225913.GA3169@intel.com>	<4D683105.70307@gmail.com>
Date: Fri, 25 Feb 2011 23:08:00 -0000
Message-ID: <AANLkTim19Y9t78D=Kjn2E7xo4iSGR2wD-71X9JqKORpH@mail.gmail.com>
Subject: Re: PATCH: PR ld/12507: Can't build a program with -flto -nostdlib
From: "H.J. Lu" <hjl.tools@gmail.com>
To: Dave Korn <dave.korn.cygwin@gmail.com>
Cc: binutils@sourceware.org
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable
X-IsSubscribed: yes
Mailing-List: contact binutils-help@sourceware.org; run by ezmlm
Precedence: bulk
List-Id: <binutils.sourceware.org>
List-Subscribe: <mailto:binutils-subscribe@sourceware.org>
List-Archive: <http://sourceware.org/ml/binutils/>
List-Post: <mailto:binutils@sourceware.org>
List-Help: <mailto:binutils-help@sourceware.org>, <http://sourceware.org/ml/#faqs>
Sender: binutils-owner@sourceware.org
X-SW-Source: 2011-02/txt/msg00321.txt.bz2

On Fri, Feb 25, 2011 at 2:45 PM, Dave Korn <dave.korn.cygwin@gmail.com> wro=
te:
> On 24/02/2011 22:59, H.J. Lu wrote:
>> We should never mark entry symbol IR only. I checked in this patch as
>> an obvious fix.
>
>> --- a/ld/plugin.c
>> +++ b/ld/plugin.c
>> @@ -490,8 +490,10 @@ get_symbols (const void *handle, int nsyms, struct =
ld_plugin_symbol *syms)
>> =A0 =A0 =A0 =A0even potentially-referenced, perhaps in a future final li=
nk if
>> =A0 =A0 =A0 =A0this is a partial one, perhaps dynamically at load-time i=
f the
>> =A0 =A0 =A0 =A0symbol is externally visible. =A0*/
>> - =A0 =A0 =A0ironly =3D !is_visible_from_outside (&syms[n], owner_sec, b=
lhe)
>> - =A0 =A0 && !bfd_hash_lookup (non_ironly_hash, syms[n].name, FALSE, FAL=
SE);
>> + =A0 =A0 =A0ironly =3D (!is_visible_from_outside (&syms[n], owner_sec, =
blhe)
>> + =A0 =A0 =A0 =A0 =A0 =A0 && !bfd_hash_lookup (non_ironly_hash, syms[n].=
name,
>> + =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0 =A0FAL=
SE, FALSE)
>> + =A0 =A0 =A0 =A0 =A0 =A0 && strcmp (syms[n].name, entry_symbol.name) !=
=3D 0);
>
> =A0This caused a bunch of regressions for me:
>
>> +FAIL: plugin claimfile resolve symbol
>> +FAIL: plugin claimfile replace file
>> +FAIL: plugin ignore lib
>> +FAIL: plugin claimfile replace lib
>
> =A0It turns out that entry_symbol.name can be NULL, and strcmp doesn't ha=
ve to
> handle null pointers gracefully; it segfaulted on cygwin. =A0We need to g=
uard
> the test, like the attached.
>
> ld/ChangeLog:
>
> 2011-02-25 =A0Dave Korn =A0<....
>
> =A0 =A0 =A0 =A0* plugin.c (get_symbols): Guard against NULL name of entry=
_symbol.
>
> =A0OK?

Sorry for that. I consider it obvious.


--=20
H.J.