From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 43699 invoked by alias); 23 Feb 2016 04:40:43 -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 43611 invoked by uid 89); 23 Feb 2016 04:40:38 -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=behave 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-pf0-f173.google.com DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; bh=UvqU356Zaz6hMaHFfgmN1AWrVcM6p5TqAAyIQcQkDdE=; b=hpiet0YXYqKb3NVYpRlSc+04Lopri1WFMfIWBZDygCgLhw+te+JsalzYwaeABTtceG MoLQ1QpHsSIRNkAMF2wGG+yPdYZx+yOpsJGKBYWZOHISbfmTHZmwX8yZq97Bjltgeipq N3XhykuKlA+Xbh+sFuCk/V20J6W9pjMqWjhXDuT+gm9oHFwlPRDBvpz65xsV/CLfn7Kb +GVdoGbLLXli8gELgkBIVUZkijf4ox1KMFcnsKnqkimTwCKAIVoRb2aiXxPSLmJUk1D6 3Cb1l+0PdQuAIkA6MPl1sO3dvxjjbwjSYRU7R4J+oxx78oPriG8Q2ZB81xOS6CchxNdm PARg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-type:content-disposition:in-reply-to :user-agent; bh=UvqU356Zaz6hMaHFfgmN1AWrVcM6p5TqAAyIQcQkDdE=; b=A2uQzVFVRex2j3GyiC5YZe2rp7ky3UFXD3LdW4jj5KpP2C6c+ypWKJWo7j9L12Xfjd cNX5ml2BubO7YhPVHOZti6Kvm9TlL+USH/z2Pb30G+jq/lG0DZvCt1hyRqb/JvIS/zxK saQ6iNMmpqxyLknU5DuYaQcN9GiZeU3jC4VSyPVHI/bRo5iuE9ZKWFHoW/f7ILyLbvFC fFaczBVQlVtdATz3nwlk8W/rA0ww1x1Mg55L9jclPfxvtHUberm7J5xncAn0nrYZzSn1 fhXC/+5f1HeYEV1xaSlJM4iqeUd8LLjWC2LXplmNMwxqHk1niHWGPv3tS93FOZONdM+T BNgQ== X-Gm-Message-State: AG10YORlxV5n+Q2vv2CXXmtnHadYGXqu21eZK60H2nPuf9oJI9uOamNGuTTp8+bExmFiCQ== X-Received: by 10.98.11.134 with SMTP id 6mr43958009pfl.109.1456202435598; Mon, 22 Feb 2016 20:40:35 -0800 (PST) Date: Fri, 01 Jan 2016 00:00:00 -0000 From: Alan Modra To: "H.J. Lu" Cc: Michael Matz , gnu-gabi@sourceware.org Subject: Re: Specify how undefined weak symbol should be resolved in executable Message-ID: <20160223044029.GE10657@bubble.grove.modra.org> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) X-SW-Source: 2016-q1/txt/msg00014.txt.bz2 On Mon, Feb 22, 2016 at 02:43:55PM -0800, H.J. Lu wrote: > we create executable with dynamic R_X86_64_32 relocation against > fun .text section, which leads to DT_TEXTREL. Is this what we want? I think that avoiding DT_TEXTREL is historically why we haven't supported weak symbols well in non-PIC executables. Another closely related issue is the old hack written into most ABIs that the address of a function referenced in an executable and defined in a shared library is the address of that function's PLT code in the executable. Note that this affects both defined and undefined weak functions in non-PIC executables. Currently, if we find a definition for "fun" at link time in a shared library, "&fun" is the PLT entry in the executable and "if (&fun)" effectively becomes "if (1)". So if you link the executable with a shared library containing a definition of "fun" but at run-time load a newer shared library *not* defining "fun", your program will segfault. Therefore, if the aim is to make PIC and non-PIC executables behave the same you need to change defined weak symbol behaviour too. Any non-PIC executable that takes the address of a weak function in code or rodata would become DT_TEXTREL. However, that might be a bad idea. Lots of C++ code uses weak symbols for functions defined in header files, and other objects with vague linkage. These result in weak definitions in eg. libstdc++.so. I'm not sure how many executables take the address of such functions and thus might become DT_TEXTREL. -- Alan Modra Australia Development Lab, IBM