From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 38677 invoked by alias); 23 Feb 2016 16:40:21 -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 38659 invoked by uid 89); 23 Feb 2016 16:40:19 -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-f51.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=5EbewxKLHBsbsTNQYNI31x3A3a4GQbyrhXmm37qZEM0=; b=Na0vo1eLX/4MVIfObA+kcw8+lWxZ0xFwjlyNl6Tj367XhmqwFjNw2pZeiAbQyPFWQ5 ODF6agcAgb9VL8Sp1JuwQYB88PMPWsFDYC0/wY6wvrU4Q+1PDzHtnG3aBRHSXkYCIimk Y4bqqaD7Sc4CdTfsZIUh4TGvdmOIeaBb6PmXmDAeIQggnNyCMI6d7YU8QR6BnyEneoPC ZjQ1RhGlZkRy7grfI4aflIoMPyP94aXgZQHqPTMtjNwZ+nuJqVSmPSkWvbVh7J4bVkBH riZrx7ZOpFyOSemwHJyMkjt6DiGygq03KxUpv4Al7iZRDfpu3Krsa7+qlV5swfw8xG3f bufw== 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=5EbewxKLHBsbsTNQYNI31x3A3a4GQbyrhXmm37qZEM0=; b=FbXSCjdUqCla9NDx+w8yEO/2sl0MbdzrGvid2+s9zoOCIovlxBzB9Ybz+X+va6H83v rfhyELahd7fIyL8s8dEt7IlL7Tj4OeD8u9T+AVgVZ5SPbKMKjvjnuAhW2G09Os2cVf8d 8guhhMGCXpDzrN5ikYi4x4Z44c28aJat5MIvxOAvRxTfajka3RnAiaj+TG4YEOlraRwU I2CNdKLrjvCs+GWzIDp6p2sqed/uoGef+rImjseNdcXPQsFJlX9dOPewk3VWvUV+CLBa r14GKgg5YJtlwH4YI1ZrK++M7q+Cukz+Avvk1ljQnUImTzMP5fIp7oBoeXLEqKj3wTSa RFlQ== X-Gm-Message-State: AG10YOQAjgR6QdwZO4ftoq57d8ru5XBHlBNbRGLVLvkeJcJMS9rL+R/Jzsct9JiBls0pB+bVEGfY6iM1n0HzaQ== MIME-Version: 1.0 X-Received: by 10.140.16.225 with SMTP id 88mr43521461qgb.96.1456245616785; Tue, 23 Feb 2016 08:40:16 -0800 (PST) In-Reply-To: <20160223044029.GE10657@bubble.grove.modra.org> 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: Alan Modra Cc: Michael Matz , gnu-gabi@sourceware.org Content-Type: text/plain; charset=UTF-8 X-SW-Source: 2016-q1/txt/msg00021.txt.bz2 On Mon, Feb 22, 2016 at 8:40 PM, Alan Modra wrote: > 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. > Not only we need to change defined weak symbol behavior, we also need to change undefined non-weak symbol behavior when taking its address. We need to generate PIC-like code to take address of a symbol in non-PIC text section. Is this what we want? -- H.J.