From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 23646 invoked by alias); 24 Feb 2016 17:23:32 -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 23620 invoked by uid 89); 24 Feb 2016 17:23:31 -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-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=0vp9dPLE8w9hhGKZlkyLQmKYdEgaXBlwVCe5ka9GgFY=; b=lew8nQISeSBze83QaIXvzCfWd3ud0tHSrgSZdTNfXezojbrZ/0Fkk4oE6PTU6BuxrA puXD9vBMTzp8OgWeIj3SLSIPv29Q5V3lgq4BPtS8NwLd6OrFhowW5A3Dof+Fpa12vcp2 ZWVktUU8iqKu0yc5JnYytpoLT3QPxMELZ4Z4GU9/YiWLsJk8XW4qI1au+HBB1zBMw5sG xREkDMIm0D8iPV68oJmPsIJufeSH5CODeU91R8YCPClkRxM+NVGn59jiaNmXAkAuW9S4 85AQawf2ZJY/h67PQchOWQruH7NUB1EOiMaJkBYds/L9AiVF3wtSnDCtJTzcfdZ8gZ1i uQgQ== 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=0vp9dPLE8w9hhGKZlkyLQmKYdEgaXBlwVCe5ka9GgFY=; b=KlNNjYpy6CXhiYmuhZbFSmfgEUivFIFnoTPyJFV0rSr8wKsAsabz8A7TzNlAUVdniq CNxfe0xmd6Ok9aeSWysU5DGAFhUb7/B4VJZInlVV5xsmqPK7ykHxrPnK84tGMwYtTRTL 7Y+/c4lSV7/NHfU+bjQ/sQep31c2QcWvY2fEugTCtnPSO0rkL65yJtA8bkkF2pm/uTId RsLU9gj+uQnB+Sat3+N6s1cL+EU3dqxePVcZR1asQ8gwMt2Wb+kPW4R9dxkElM9CQsGu ley91ZiTAavUhsQ6xzw0GOx1eUKm42TVhV/bKreQIT90igR6JVq1PKrGzIQGGNZmh9gc DNyw== X-Gm-Message-State: AG10YOS9W7P4ZhITGAq1g2Z4yT+b6UD/52o4TzZua7E4Acri5vRYpLrpAWK/nhRzg0I3Sj3h7/fcr4sTJFi3UA== MIME-Version: 1.0 X-Received: by 10.140.16.225 with SMTP id 88mr50997324qgb.96.1456334608263; Wed, 24 Feb 2016 09:23:28 -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/msg00035.txt.bz2 On Wed, Feb 24, 2016 at 9:08 AM, Michael Matz wrote: > 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. I suggest you raise this issue at https://groups.google.com/forum/#!forum/generic-abi -- H.J.