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 C41B4C28D18 for ; Wed, 5 Jun 2019 18:42:48 +0000 (UTC) Received: from vger.kernel.org (vger.kernel.org [209.132.180.67]) by mail.kernel.org (Postfix) with ESMTP id A42EE20872 for ; Wed, 5 Jun 2019 18:42:48 +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 S1726502AbfFESms (ORCPT ); Wed, 5 Jun 2019 14:42:48 -0400 Received: from mail-it1-f193.google.com ([209.85.166.193]:33334 "EHLO mail-it1-f193.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726691AbfFESms (ORCPT ); Wed, 5 Jun 2019 14:42:48 -0400 Received: by mail-it1-f193.google.com with SMTP id v193so240564itc.0 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=QgkP4syQuWAA+9kQHpVQlPBMFzqYDUVS2LRqJyNjOjAYI3TVTm/xk++hySI+rY7z8B qzqwrbme9DmLfji5wWlG8TCS7Md3piOILfsP1L1IxwtlEWSiiohAQh2Wh4g8B9yrBFvj ai/auWq5MsOi9/wonYt+EKvjkRhz5yxcyCAOoK7fwGoToqIw1NZaid1bZhfzQjTcm9ZT Q0LRtyMOKi2xWhME1bOdGM60ZimphltFF6tOfrDpgsBAwmX16GomT/0CI34Djw/99nja s6E4cQ4XZaLMdNq2geZxXmFMV69ft3llx7PBrTFd9nZ516V/dxyDwKjB7uGzEd/9tOJD Ybzw== X-Gm-Message-State: APjAAAX4D/s+vJDVO2Ie6zmpe3clsjNeMQP1POtbG8vPJEa3NSAv91o7 +bNvlOc44842RHGm1xaBUJQqcGoX8S4GV3O24tLVZg== 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-efi-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-efi@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