From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 65134 invoked by alias); 24 Feb 2016 17:08:18 -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 65123 invoked by uid 89); 24 Feb 2016 17:08:17 -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=-1.9 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_NONE,RP_MATCHES_RCVD,SPF_PASS autolearn=ham version=3.3.2 spammy= X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00,RCVD_IN_DNSWL_NONE,RP_MATCHES_RCVD,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: mx2.suse.de X-Virus-Scanned: by amavisd-new at test-mx.suse.de Date: Fri, 01 Jan 2016 00:00:00 -0000 From: Michael Matz To: "H.J. Lu" cc: Carlos O'Donell , Alan Modra , gnu-gabi@sourceware.org Subject: Re: Specify how undefined weak symbol should be resolved in executable In-Reply-To: Message-ID: References: <20160223044029.GE10657@bubble.grove.modra.org> <20160224010458.GF10657@bubble.grove.modra.org> <20160224015659.GH10657@bubble.grove.modra.org> <56CD0FC8.4030202@redhat.com> User-Agent: Alpine 2.20 (LSU 67 2015-01-07) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII X-SW-Source: 2016-q1/txt/msg00034.txt.bz2 Hi, On Wed, 24 Feb 2016, H.J. Lu wrote: > >> 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? Like right now (mostly)? Resolution of weak symbols needs to be deferred to the dynamic linker, in particular they mustn't be resolved (to either zero or an address) at link edit time. There's one case where weak symbols can be resolved early: if at link edit time the executable itself provides a definition of 'foo' then weak references can be directly resolved to that one (because at runtime of that exectuable there's no possibility to not have this symbol defined). To not do that (i.e. resolve them always at link edit time) breaks various current uses of weak symbols. We could do that of course, but I don't think that would be useful to users. Ciao, Michael.