From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 3999 invoked by alias); 18 Apr 2016 17:04:07 -0000 Mailing-List: contact binutils-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: binutils-owner@sourceware.org Received: (qmail 3962 invoked by uid 89); 18 Apr 2016 17:04:06 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE,RP_MATCHES_RCVD,SPF_PASS autolearn=ham version=3.3.2 spammy= X-HELO: mailapp01.imgtec.com Received: from mailapp01.imgtec.com (HELO mailapp01.imgtec.com) (195.59.15.196) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 18 Apr 2016 17:04:05 +0000 Received: from hhmail02.hh.imgtec.org (unknown [10.100.10.20]) by Websense Email with ESMTPS id E74F5C47DB353; Mon, 18 Apr 2016 18:03:58 +0100 (IST) Received: from [10.20.78.233] (10.20.78.233) by hhmail02.hh.imgtec.org (10.100.10.21) with Microsoft SMTP Server id 14.3.266.1; Mon, 18 Apr 2016 18:04:01 +0100 Date: Mon, 18 Apr 2016 17:04:00 -0000 From: "Maciej W. Rozycki" To: "H.J. Lu" CC: Alan Modra , Richard Biener , Jeff Law , Cary Coutant , Joe Groff , Binutils , GCC Subject: Re: Preventing preemption of 'protected' symbols in GNU ld 2.26 [aka should we revert the fix for 65248] In-Reply-To: Message-ID: References: <983472E1-A1BC-4970-9CF9-0138A6BAD16D@apple.com> <6AAD87D2-90F9-4AD7-A195-AC91B76EA6AE@apple.com> <56FB5061.9010303@redhat.com> <20160330143421.GM15812@bubble.grove.modra.org> <571161D0.10601@redhat.com> <20160418144911.GG15088@bubble.grove.modra.org> User-Agent: Alpine 2.00 (DEB 1167 2008-08-23) MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" X-SW-Source: 2016-04/txt/msg00275.txt.bz2 On Mon, 18 Apr 2016, H.J. Lu wrote: > > Any testcase the takes the address of a protected visibility variable > > defined in a shared library now can get the wrong answer, since you > > can argue that any address outside the shared library is wrong > > according to the gABI. > > What value should you get when taking an address of a function > with protected visibility inside the shared library? Should it be > pointed to the function body or its PLT entry in the executable > which calls the function? I think it has to be an address within the shared library itself, that is -- depending on the particular psABI -- either the function body or its corresponding PLT entry in the DSO, but not in the main executable. The reason is DSO code (also handcoded assembly) may reasonably expect to be able to load the address with a PC-relative load-address type instruction (ADDIUPC, LEA, MOVAB, etc.) and the target may not even have suitable dynamic relocations available to apply any load-time fixup if the symbol referred turns up outside of the DSO. The instruction used may have a PC-relative range limit too. Maciej