From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-1.1 required=3.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,HEADER_FROM_DIFFERENT_DOMAINS,MAILING_LIST_MULTI,SPF_HELO_NONE, SPF_PASS,URIBL_BLOCKED autolearn=unavailable autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 77FFFC28CC6 for ; Wed, 5 Jun 2019 18:42:49 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id 576F3206B8 for ; Wed, 5 Jun 2019 18:42:49 +0000 (UTC) Authentication-Results: mail.kernel.org; dkim=pass (2048-bit key) header.d=linaro.org header.i=@linaro.org header.b="FFyb5FTw" Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726722AbfFESms (ORCPT ); Wed, 5 Jun 2019 14:42:48 -0400 Received: from mail-it1-f193.google.com ([209.85.166.193]:37526 "EHLO mail-it1-f193.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726535AbfFESms (ORCPT ); Wed, 5 Jun 2019 14:42:48 -0400 Received: by mail-it1-f193.google.com with SMTP id s16so5185347ita.2 for ; Wed, 05 Jun 2019 11:42:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=linaro.org; s=google; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=tb3AsUPpK2GIv5fgvYVpcgDU5/gP5sotzobQUmB0Ib4=; b=FFyb5FTwdfq2lfjZ5UNKjnE3e/r2uFUyCmOfyJOpedhml6nw+BGdFwpyxfyHPD0f7/ rEO++unxGsKdphMqlpJPq2jyYUMAWpffYXZ2+0gW6fsNLVLp+GWNoKIx4Bvsv/j8a+hW CW8hPN8Yi1Yw8Zek7YkvFBYng6BFuOrxm5I0y57dm/M345vnLUtQtwD4f/O7qOk7IN/1 xGwZV922z7gBwDtBR+S0sTufgi3FxQ1oZZRNOq+Raf9ABT81ncZGmTDLtZcQayocqwLM WVMXajhLQmGEr8m6UvDIIw3OGpkM5Zfm7MzgV/uGk3uu95oIKBBZz06Mf4twZHzwCurG LYCg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=tb3AsUPpK2GIv5fgvYVpcgDU5/gP5sotzobQUmB0Ib4=; b=Fyz8ESBCoa6hC3LQ+BXG2kd3BZluHfDpncFIo2GOXT3XWqGg3q/vCEcqBDTs+6C6s8 REY/MtHjX2tqWMt/3gsF7OVEYgCg2LIKwNhfIop1WtJ39bfs69uifY8FI+0lE/6E5eje uUlEliqfs7p2xqLst5XoHPAkweadjx2fIk0Ns2NSaV7+pFcu8de2kU26odVxAfHyPDzc fA1XAFZMLcKhKf+GiaR947ACNir2DqBZTFPyCYV4Lse/1ExWZMSZ3Np/YU2ZPVOGC4Md 94VjLi0UzK6yTN4osVXpC+j+M8sOkHhBV+Tb3THkrWkE8dsuPiDWCMOK1tPzYlomhulK qu0Q== X-Gm-Message-State: APjAAAWTdvMiGGqxfQnTwtKnRhCbZiotD8MeqPIiT/0k+VBTavEPIr64 dxucZgHqsyZTH0UOyLhey7B99FiSrwu6StEPTHlc7Q== X-Google-Smtp-Source: APXvYqxakciBcE0cDitL0gdocex8qsiZFZdUy6cXYeX5t4/xGuD1tW+v4IIDXMqIolO29RI1u+y81tpFSB0UKkNdcms= X-Received: by 2002:a24:740f:: with SMTP id o15mr12084363itc.76.1559760167133; Wed, 05 Jun 2019 11:42:47 -0700 (PDT) MIME-Version: 1.0 References: <779905244.a0lJJiZRjM@devpool35> <20190605162626.GA31164@kroah.com> In-Reply-To: <20190605162626.GA31164@kroah.com> From: Ard Biesheuvel Date: Wed, 5 Jun 2019 20:42:32 +0200 Message-ID: Subject: Re: Building arm64 EFI stub with -fpie breaks build of 4.9.x (undefined reference to `__efistub__GLOBAL_OFFSET_TABLE_') To: Greg KH Cc: Rolf Eike Beer , Nick Desaulniers , Linus Torvalds , Matt Fleming , Peter Zijlstra , Thomas Gleixner , linux-efi , Linux Kernel Developers List , stable Content-Type: text/plain; charset="UTF-8" Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Wed, 5 Jun 2019 at 18:26, Greg KH wrote: > > On Wed, Jun 05, 2019 at 05:19:40PM +0200, Rolf Eike Beer wrote: > > I decided to dig out a toy project which uses a DragonBoard 410c. This has > > been "running" with kernel 4.9, which I would keep this way for unrelated > > reasons. The vanilla 4.9 kernel wasn't bootable back then, but it was > > buildable, which was good enough. > > > > Upgrading the kernel to 4.9.180 caused the boot to suddenly fail: > > > > aarch64-unknown-linux-gnueabi-ld: ./drivers/firmware/efi/libstub/lib.a(arm64- > > stub.stub.o): in function `handle_kernel_image': > > /tmp/e2/build/linux-4.9.139/drivers/firmware/efi/libstub/arm64-stub.c:63: > > undefined reference to `__efistub__GLOBAL_OFFSET_TABLE_' > > aarch64-unknown-linux-gnueabi-ld: ./drivers/firmware/efi/libstub/lib.a(arm64- > > stub.stub.o): relocation R_AARCH64_ADR_PREL_PG_HI21 against symbol > > `__efistub__GLOBAL_OFFSET_TABLE_' which may bind externally can not be used > > when making a shared object; recompile with -fPIC > > /tmp/e2/build/linux-4.9.139/drivers/firmware/efi/libstub/arm64-stub.c:63: > > (.init.text+0xc): dangerous relocation: unsupported relocation > > /tmp/e2/build/linux-4.9.139/Makefile:1001: recipe for target 'vmlinux' failed > > -make[1]: *** [vmlinux] Error 1 > > > > This is caused by commit 27b5ebf61818749b3568354c64a8ec2d9cd5ecca from > > linux-4.9.y (which is 91ee5b21ee026c49e4e7483de69b55b8b47042be), reverting > > this commit fixes the build. > > > > This happens with vanilla binutils 2.32 and gcc 8.3.0 as well as 9.1.0. See > > the attached .config for reference. > > > > If you have questions or patches just ping me. > > Does Linus's latest tree also fail for you (or 5.1)? > > Nick, do we need to add another fix that is in mainline for this to work > properly? > For the record, this is an example of why I think backporting those clang enablement patches is a bad idea. We can't actually build those kernels with clang, can we? So what is the point? It would be helpful to get a relocation dump (objdump -r) of arm64-stub.o to figure out which symbol needs a 'hidden' annotation to prevent GCC from emitting it as a PIC reference requiring a GOT. Alternatively, we can just revert this patch from 4.9