From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 49488 invoked by alias); 23 Feb 2016 18:05:55 -0000 Mailing-List: contact gnu-gabi-help@sourceware.org; run by ezmlm Precedence: bulk List-Post: List-Help: List-Subscribe: Sender: gnu-gabi-owner@sourceware.org Received: (qmail 49469 invoked by uid 89); 23 Feb 2016 18:05:53 -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=implications, Hx-languages-length:2097 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-f42.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=yErVepg9wy1vQN/QelMK0XfEhnGstTm0ym+WdrdL/lA=; b=NmATBGQF1W+gZAeUT7Lt9KW35B8Tq+nLDPoInRPTHaVatb+OdxtlfoMwmZPbqWwjmW 2ZKPQsXsBKCZBzIKQ4TmJic4vVEmfXRXPCqMuwBL82GWmoGVJGzKjiSe4u0do44ZMV+N Q0XvK5bdN/1vNIcS2lZZ7oWLIjn949enMP7EWXoRbHj2wniydBbm9ZijOyKpkWd4gcSc OpqrB97flSPjI6pnx954iKb4gB5rYemNpQS7hbm3OiffgY6UFrcTtwtXX0yH3E/rUnoI fh/DDFn4Ta5gCa3D2VENXM9TWZi//O3ESY7jXeD4o6quGJE4vtl3K3QgcTmvInbnpZ4d 6cmQ== 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=yErVepg9wy1vQN/QelMK0XfEhnGstTm0ym+WdrdL/lA=; b=XwBpvDJRDTjafXdHRiSYOYh9Dz8DEH1RXtOsJpd9id/QYN+QUjUCnYX+DYOHLZ29mO xDGbvb48Pjcgb3cVu5nqk/vOyCAtRZ3FusdSbWObdU/U3FEYfF8b6SUX1lPYpl9jqyFI QHhtCQ3gjlPoKlGfrNYd/H5zX2S3iwsx+j/f8PEa2cDHkGpRuvAv6S4qxtsYUmJ6/m6/ Y6FOl/9z26h7G4XHp/EmXL21M03chgoJwaSyRiafW6aWxiLo89CP9F0zTGI/B88d54Y3 bOSNyHp0ScNjox8W5sKG6Ohd1ohDNkMIjOc1yBc5hYLP6bzU5hhr5LrCwucdtnxV4O38 4XcQ== X-Gm-Message-State: AG10YORPoVdRFvAUe5iO2ORTEhu+XHTYO8HdZdksWUzIFLM0FHuLglsAXOGVlDDBbQGcovHEYUEQvu8RFyXIQw== MIME-Version: 1.0 X-Received: by 10.140.169.9 with SMTP id p9mr45820162qhp.50.1456250750440; Tue, 23 Feb 2016 10:05:50 -0800 (PST) In-Reply-To: References: <20160223044029.GE10657@bubble.grove.modra.org> 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: Alan Modra , gnu-gabi@sourceware.org Content-Type: text/plain; charset=UTF-8 X-SW-Source: 2016-q1/txt/msg00026.txt.bz2 On Tue, Feb 23, 2016 at 9:10 AM, H.J. Lu wrote: > On Tue, Feb 23, 2016 at 9:01 AM, Michael Matz wrote: >> Hi, >> >> On Tue, 23 Feb 2016, H.J. Lu wrote: >> >>> >> Not only we need to change defined weak symbol behavior, we also need >>> >> to change undefined non-weak symbol behavior when taking its address. >>> > >>> > Why? An undefined non-weak symbol reference leads to a linker error, >>> > done. Why change that? >>> >>> Make it "external non-weak symbol", which is a symbol defined in a >>> shared object. >> >> What would you like to change in behaviour for them (and why must it be >> done at the same time as changing something for weak symbols)? A >> reference to the address of such a function symbol from an executable >> resolves to the plt slot currently (which in turn is exported, so that >> address references from other modules resolve to the same). A reference >> to a non-function symbol is loaded from the got. In all cases must this >> symbol be defined somewhere (otherwise linker error), so I don't see what >> we need to change, nor why that would force DT_TEXTREL (or the compiler to >> emit PIC like code). >> > > At run-time, there is no difference between weak defined and non-weak > defined symbols. If we change defined weak symbol behavior, we also > need to change defined non-weak symbol behavior. > I will check this patch: https://sourceware.org/ml/binutils/2016-02/msg00339.html into binutils master branch to make behaviors of static executable, dynamic executable and position independent executable consistent with references to undefined weak and defined symbols, regardless if the relocatable input is compiled with PIC or not. I created users/hjl/pr19704 branch to treat undefined weak symbol in the executable as dynamic, requiring dynamic relocation, on x86 via a command line switch: -z dynamic-undefined-weak Treat undefined weak symbol as dynamic We need to fully investigate its implications before moving forward with it. -- H.J.