From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 86497 invoked by alias); 23 Feb 2016 17:10: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 86479 invoked by uid 89); 23 Feb 2016 17:10:54 -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=Hx-languages-length:1349 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-f49.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=BQwFadFSSpTCm6UE1KTTs7R/T6cNm+BiS4d6S5IspQM=; b=mN5nPN/6PfTzR7HdbYJva28vwvcOngq2x+SAZMEoyI09LyyEiXzxl2X4AWKBvPYwjr uWu2/bMLcBlMvNcaavJA63sn5LQXzGEHUoj/Kv452t5I4OxleWr8BqthyLGZ/UljoUYz V/euwTJV1texV+aQQGkXL39tD/QUm1d9x6w+xEfBQKZp9RC9agkQExRQRc4PFwIUAxss b7rkEah+6rzq7VKf0h/theAF1bgJIiM9Jg7mAksQOWknRZ3bklcwQcdIy05zIBJ4QYjc Hvt5OGlLF4bhNYwlelEqbFNI3jFyjVrA7QIasO2NqIeaLjelDCuv0A2XTRnxGGJmOoIp 2ImQ== 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=BQwFadFSSpTCm6UE1KTTs7R/T6cNm+BiS4d6S5IspQM=; b=QUdOwp8557m/dVidix5XoC35r6PY8E3fyn/d/5X/bGNbD5y1892nh7YOW5I7vxK68R YrzG1nCyWEnkjNddPpmCS9vXkR3pfsEPTSmyLErVG3nvakBU0eOG4CbWgM1u02+KUQTO 0XTuBxcrYeuLwJLyqD+S9dYb6Y49X9tujUkTOzy+tp1FhPNAXjn/vitgQgt9KSwJcH8e qi7ZDaNusLa/x1DjpImwhgyCVh5keSzAUVACR7kQO2kvCYUVi4cNp2b0Z+H0qV6o9D2E SHVIoEKEcAzEY5GUIpJ2KX5aqUA3BdV3d5eXdibDCR9ocwChdui+xQFWlFqerOrMb8F9 1uFQ== X-Gm-Message-State: AG10YOTX5DLjaAjSyCHjPJR0ZGkl3NU/WYheR/JzGMLO2JAIW1l822I7Blz6wxOLh8t2FY/xEsGb92YzbpLeCg== MIME-Version: 1.0 X-Received: by 10.140.16.225 with SMTP id 88mr43722148qgb.96.1456247451286; Tue, 23 Feb 2016 09:10:51 -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/msg00025.txt.bz2 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. -- H.J.