From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753504AbaIDLYp (ORCPT ); Thu, 4 Sep 2014 07:24:45 -0400 Received: from youngberry.canonical.com ([91.189.89.112]:36192 "EHLO youngberry.canonical.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753276AbaIDLYn (ORCPT ); Thu, 4 Sep 2014 07:24:43 -0400 Message-ID: <54084BF7.8090900@canonical.com> Date: Thu, 04 Sep 2014 13:24:39 +0200 From: Maarten Lankhorst User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.0 MIME-Version: 1.0 To: Ard Biesheuvel CC: Matt Fleming , Ulf Winkelvos , Matt Fleming , LKML , "x86@kernel.org" , "H. Peter Anvin" , "linux-efi@vger.kernel.org" , Seth Forshee , Matthew Garrett Subject: Re: [REGRESSION] "efi: efistub: Convert into static library" and preparation patches References: <5405E186.2080406@canonical.com> <20140902192941.GB3001@console-pimps.org> <5406D0DB.90401@canonical.com> <54073409.6030004@canonical.com> <20140903175948.GH3001@console-pimps.org> <54084376.8090002@canonical.com> In-Reply-To: Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Op 04-09-14 om 13:19 schreef Ard Biesheuvel: > >> On 4 sep. 2014, at 12:48, Maarten Lankhorst wrote: >> >> Op 03-09-14 om 21:57 schreef Ard Biesheuvel: >>> On 3 September 2014 19:59, Matt Fleming wrote: >>>> On Wed, 03 Sep, at 05:37:26PM, Ard Biesheuvel wrote: >>>>> Will do, thanks. >>>>> >>>>> @Matt: so there is two ways to fix this, the patch above addressing >>>>> this single instance, and alternatively, adding a #pragma GCC >>>>> visiblilty push(hidden) to all .c files under libstub/, *before* the >>>>> #includes. The latter would catch future problems regarding newly >>>>> introduced global variables, but it may be a bit overkill in this >>>>> case, as libstub is not expected to be in flux in the foreseeable >>>>> future. >>>>> >>>>> Any preferences? >>>> Any reason we can't reuse the existing GOT fixup code in the early x86 >>>> boot code? We're not executing it before the EFI boot stub atm, which is >>>> the reason Maarten is hitting these difficulties. >>> I guess that is likely to work, I just wasn't aware it existed :-) >>> I think adding another visibility(hidden) attribute or 2 would >>> complete eliminate the need for GOT fixups, but I guess that is more >>> sensitive to compiler versions being recent enough etc. >>> The attached (build tested only) patch eliminates all GOT relocations >>> under boot/compressed for a 64-bit EFI stub build. >>> >>>> Maarten, does the following help? >>>> >>>> If not, Ard please go ahead with option #2 above. Overkill yes, but I've >>>> done the single __attribute__() hacks in other projects and someone >>>> (usually me) always eventually forgets to tag some instance. >>> It appears we just got lucky on arm64, since we don't have any global >>> variables, but the issue does exist there as well. >> FWIW, visibility pushing doesn't seem to work for functions declared with extern. > Are you sure you are seeing GOT entries being generated for functions? Normally, these are resolved via PLT entries, and those usually don't result in GOT entries to be allocated unless the branch target is unknown at link time. > No not really, I was just looking at GOTPCREL for the .o files, no idea if they resulted in any actual relocations or not. ~Maarten