From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 71060 invoked by alias); 24 Feb 2016 15:45:10 -0000 Mailing-List: contact gnu-gabi-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Post: List-Help: List-Subscribe: Sender: gnu-gabi-owner@sourceware.org Received: (qmail 71038 invoked by uid 89); 24 Feb 2016 15:45:09 -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=highly 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-qg0-f54.google.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=SSQkZ70Ezd1I8NFkDjUaE4559rxAzcpmpxiifuV/gAQ=; b=Tp9wJ8MsKlo0KgNdzNTwY61ZEn+ocYeT9rsmzqBwHd5AyEm19iJOeSY6IQ0G/T12rG EIgHMsR/CZn1u7ePZUgvrmNE4O7sPZ+/vwdbQQ4PVLaUsCI1lQ+DgywRfwlnuQW/OZMX 1tIT7P/4YpX3RtObTaWMDH2KkRFbTBBROn7tnHDg4IpPaDTdqMsrd6SJtAsimzlTIG1F OrfcnwDCRYeLMbf1ggb+JSX6D7b5I5EVvxduXZ0wS0IdvTgiwowBFrvXfuKx8RteY+zg YOPhjoLvEfOs5SKvz9lDtaTrRo1dMx6Jgt4UvMbhN9WTWZiSh9bgehudc34SRuLa8KhK AmjQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=SSQkZ70Ezd1I8NFkDjUaE4559rxAzcpmpxiifuV/gAQ=; b=eCFe7TuVUjvxxPakci8/rWfqXrGI/K9aOJ9OhxoSaBnRDvCSVXralMuq2gFDo6GO7b r6ros3YGUQYD4FU6fMKF8BTBCWE7Ei1+MRk9kRcvf34SqBCX5fADmnF0TXRvvCfQBdKj nOJhSCoKNj4XT7WazAAwnKXyWOJpJwfth+j0u1msvoj1KacVEwx4sxU6UavXloyPh9s3 kd5cPzdtKZohJOzhm3TOrioYEsHZVtKUFoXzApODI9NlnpQaZhoHCpUF0ns153hy0p89 pyx7hu5WHizrwvR/bKNFhLi1SG0zuTOeIKrf6x8Y48Ayq4Ag9KJYduQzzAtf8l6t6V1P ZKaA== X-Gm-Message-State: AG10YOSdR8StQSNqs58JoCcStOqx6eS5qwhY/k+rOcY+sI3S914WTFTOX68b1V9+fza1dq2h9pnDpXApSuFZmg== MIME-Version: 1.0 X-Received: by 10.140.19.52 with SMTP id 49mr49381566qgg.103.1456328706298; Wed, 24 Feb 2016 07:45:06 -0800 (PST) In-Reply-To: References: <20160223044029.GE10657@bubble.grove.modra.org> <20160224010458.GF10657@bubble.grove.modra.org> <20160224015659.GH10657@bubble.grove.modra.org> <56CD0FC8.4030202@redhat.com> Date: Fri, 01 Jan 2016 00:00:00 -0000 Message-ID: Subject: Re: Specify how undefined weak symbol should be resolved in executable From: "H.J. Lu" To: Michael Matz Cc: "Carlos O'Donell" , Alan Modra , gnu-gabi@sourceware.org Content-Type: text/plain; charset=UTF-8 X-SW-Source: 2016-q1/txt/msg00033.txt.bz2 On Wed, Feb 24, 2016 at 7:30 AM, Michael Matz wrote: > Hi, > > On Wed, 24 Feb 2016, H.J. Lu wrote: > >> > Agreed. Anything that brings back weak symbols into the dynamic loader >> > is going to be highly suspect to me, and require a lot of explaining. >> >> I was saying as far as ld was concerned, weak defined and non-weak >> defined dynamic symbols would be treated equally at run-time. Do you >> agree with me? > > I at least don't. The difference is that a defined weak symbol (at link > edit time) might become undefined at runtime. A defined non-weak symbol > can't. So they have to be handled differently. > How? -- H.J.