From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 71633 invoked by alias); 18 Apr 2016 17:57:50 -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 71494 invoked by uid 89); 18 Apr 2016 17:57:49 -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=unavailable version=3.3.2 spammy=thunk, fulfils, annotation, addressing 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:57:41 +0000 Received: from hhmail02.hh.imgtec.org (unknown [10.100.10.20]) by Websense Email with ESMTPS id E2A1C5A491B84; Mon, 18 Apr 2016 18:57:34 +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:57:37 +0100 Date: Mon, 18 Apr 2016 17:57:00 -0000 From: "Maciej W. Rozycki" To: Michael Matz CC: "H.J. Lu" , 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/msg00281.txt.bz2 On Mon, 18 Apr 2016, Michael Matz wrote: > E.g. one limitation might very well be that function pointer comparison > for protected functions doesn't work (gives different outcomes if the > pointer is built from inside the exe or from a shared lib). (No matter > how it's built, it will still _work_ when called). Alternatively we can > make comparison work (by using the exe PLT slot), in which case Alans > testcase will need more complications to show that protected visibility > currently is broken. Alans testcase will work right now (as in showing > protected being broken) on data symbols. The way it works in the original MIPS SVR4 psABI is by using the relevant GOT entry's contents as the pointer, disabling lazy binding for any function symbols whose value is used as data rather than to make a call (no lazy binding stub is simply produced). It's easy in that psABI because all code is PIC, even in executables -- which fulfils Cary's earlier postulate for protected symbol accesses. For non-PIC code the necessary arrangement can be made by the compiler based on symbol annotation (also proposed by Cary), or failing that a link-time fixup can be made, possibly branching to a thunk generated out of line if the sequence required to load a GOT entry is longer than the original absolute sequence (proposed by Alan). I think this approach should work with x86 even, as its branch instruction has a single-byte opcode and a signed 32-bit span, so it certainly does not require more code space than any relocated instruction using the absolute or PC-relative addressing mode. Maciej