From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <gnu-gabi-return-29-listarch-gnu-gabi=sourceware.org@sourceware.org>
Received: (qmail 25906 invoked by alias); 24 Feb 2016 01:05:07 -0000
Mailing-List: contact gnu-gabi-help@sourceware.org; run by ezmlm
Precedence: bulk
List-Post: <mailto:gnu-gabi@sourceware.org>
List-Help: <mailto:gnu-gabi-help@sourceware.org>
List-Subscribe: <mailto:gnu-gabi-subscribe@sourceware.org>
Sender: gnu-gabi-owner@sourceware.org
Received: (qmail 25874 invoked by uid 89); 24 Feb 2016 01:05:07 -0000
Authentication-Results: sourceware.org; auth=none
X-Virus-Checked: by ClamAV 0.99 on sourceware.org
X-Virus-Found: No
X-Spam-SWARE-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 spammy=
X-Spam-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2
X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on sourceware.org
X-Spam-Level: 
X-HELO: mail-pa0-f48.google.com
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=gmail.com; s=20120113;
        h=date:from:to:cc:subject:message-id:references:mime-version
         :content-type:content-disposition:in-reply-to:user-agent;
        bh=innH7vU5Q1FYuHoCOKG69y3Kcf3NfuksWKrVHIJW2yM=;
        b=WiIBPORR6tKWTu/yMCMacLp/4UOUuPjUfNoa7c4Js0VFECuEWsbNap0i9U4sr7LkNT
         9SKhQM8xPwFuVCLwiKvF/8QLw92Ro2EmvAqYRWiDwiJG4GiFb22Ejp+n52CDa1M5fjD7
         KmABY3InlSe3nXhljOV3ZVRwKKHPczcShRY1DQ3+XGvuugj4G9P0DwuOCq/rzCOSGFQD
         e2zDTVN7ZsrmbzmyC9QpqnROj7Js+iOgjzhMDliHQQRamgqhX20bKT3d+DL5FlZD/Xwi
         xsrD0EABHdMsGMEUXLD1biFaxrbq0vCC/elM7T+K+eL777xwNkto4dPqB7vmhNwPJXIx
         aS1A==
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
        d=1e100.net; s=20130820;
        h=x-gm-message-state:date:from:to:cc:subject:message-id:references
         :mime-version:content-type:content-disposition:in-reply-to
         :user-agent;
        bh=innH7vU5Q1FYuHoCOKG69y3Kcf3NfuksWKrVHIJW2yM=;
        b=l7YiEFtzl5leuD1TLnAYN4ggeRocHdFCwfLCKBNNCmRlBK8W1lY+TSuPFLmTJsulbO
         njAfsXecrv/2yzBWZm/IDtBrqBl1SBz5+6v1DQ5uWqyu0cCvSNTcEsF7P9T2FExgBHHA
         EtF0pa34HSuJUglR7ojtjx/K2tThyJCwhPrL3T+cpOe33qP1hifj038bkUPJ6jbbMw+l
         qLsR48yZP9xt7avi1ZZ4IJLGAJf2w3avFsme0JTkLnPCvNBtwD/Q1Mqc/ETQTHEwTIa0
         WvOwoS4azQCUhyhfm785QFZr+P+0ni+JRlXduVKORTlvS7fpHaXQp0iwbA3BONDydBOh
         99fw==
X-Gm-Message-State: AG10YORwuBnjTIxFrcfMQhKWJI5Lt+aHoRdlDb2zZy6LB4gsXZEKIyyIjTmSwG2lxfedPg==
X-Received: by 10.66.62.226 with SMTP id b2mr50648732pas.94.1456275904485;
        Tue, 23 Feb 2016 17:05:04 -0800 (PST)
Date: Fri, 01 Jan 2016 00:00:00 -0000
From: Alan Modra <amodra@gmail.com>
To: "H.J. Lu" <hjl.tools@gmail.com>
Cc: Michael Matz <matz@suse.de>, gnu-gabi@sourceware.org
Subject: Re: Specify how undefined weak symbol should be resolved in
 executable
Message-ID: <20160224010458.GF10657@bubble.grove.modra.org>
References: <CAMe9rOrP0fxgT9tuZaNFdGJFNGAghO8dupcyy-w-nm6E3eZzkA@mail.gmail.com>
 <alpine.LSU.2.20.1602221914130.20277@wotan.suse.de>
 <CAMe9rOoqOvXXOjLKnyg0OPpPE4pEvN4kO6+e7nWz7Ng9LTBwSg@mail.gmail.com>
 <CAMe9rOq=aMiTZ_nwS9aO9ba5bj_ak4gpk9D+JSfwged70VM3mg@mail.gmail.com>
 <20160223044029.GE10657@bubble.grove.modra.org>
 <CAMe9rOokycUczJ-F8rafSoTygz0emiCUHz3FwVObCf=HPun=ew@mail.gmail.com>
 <alpine.LSU.2.20.1602231748430.20277@wotan.suse.de>
 <CAMe9rOrFK5+AQJ1RepMD_R3Kw+s5Yg3k8C-PEmMTt1MtC3tKng@mail.gmail.com>
 <alpine.LSU.2.20.1602231756490.20277@wotan.suse.de>
 <CAMe9rOpQ4Fwk7wJNQuW_5VFuZTApuixt5e=NdrUmZccYK17cCg@mail.gmail.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <CAMe9rOpQ4Fwk7wJNQuW_5VFuZTApuixt5e=NdrUmZccYK17cCg@mail.gmail.com>
User-Agent: Mutt/1.5.23 (2014-03-12)
X-SW-Source: 2016-q1/txt/msg00027.txt.bz2

On Tue, Feb 23, 2016 at 09:10:51AM -0800, H.J. Lu wrote:
> At run-time, there is no difference between weak defined and non-weak
> defined symbols.

This is not true, and even if it was..

>  If we change defined weak symbol behavior, we also
> need to change defined non-weak symbol behavior.

..it does not follow that run-time loader treatment of weak vs. strong
symbols should determine linker behaviour regarding the same.

-- 
Alan Modra
Australia Development Lab, IBM