From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1750939AbdEIVtJ (ORCPT ); Tue, 9 May 2017 17:49:09 -0400 Received: from mail-pg0-f52.google.com ([74.125.83.52]:36747 "EHLO mail-pg0-f52.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750734AbdEIVtH (ORCPT ); Tue, 9 May 2017 17:49:07 -0400 Date: Tue, 9 May 2017 14:49:05 -0700 From: Matthias Kaehlcke To: Greg Hackmann Cc: Matt Fleming , Ard Biesheuvel , linux-efi@vger.kernel.org, linux-kernel@vger.kernel.org, Grant Grundler , Michael Davidson , Bernhard =?utf-8?Q?Rosenkr=C3=A4nzer?= Subject: Re: [PATCH] efi/libstub: Indicate clang the relocation mode for arm64 Message-ID: <20170509214905.GH128305@google.com> References: <20170509193612.64105-1-mka@chromium.org> <25d94b46-765e-f12f-a287-853c76782143@google.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <25d94b46-765e-f12f-a287-853c76782143@google.com> User-Agent: Mutt/1.5.21 (2010-09-15) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org El Tue, May 09, 2017 at 01:50:36PM -0700 Greg Hackmann ha dit: > On 05/09/2017 12:36 PM, Matthias Kaehlcke wrote: > >From: Greg Hackmann > > > >Without any extra guidance, clang will generate libstub with either > >absolute or relative ELF relocations. Use the right combination of > >-fpic and -fno-pic on different files to avoid this. > > > >Signed-off-by: Greg Hackmann > >Signed-off-by: Bernhard Rosenkränzer > >Signed-off-by: Matthias Kaehlcke > >--- > > drivers/firmware/efi/libstub/Makefile | 6 ++++++ > > 1 file changed, 6 insertions(+) > > > >diff --git a/drivers/firmware/efi/libstub/Makefile b/drivers/firmware/efi/libstub/Makefile > >index f7425960f6a5..ccbaaf4d8650 100644 > >--- a/drivers/firmware/efi/libstub/Makefile > >+++ b/drivers/firmware/efi/libstub/Makefile > >@@ -11,6 +11,9 @@ cflags-$(CONFIG_X86) += -m$(BITS) -D__KERNEL__ -O2 \ > > -mno-mmx -mno-sse > > > > cflags-$(CONFIG_ARM64) := $(subst -pg,,$(KBUILD_CFLAGS)) > >+ifeq ($(cc-name),clang) > >+cflags-$(CONFIG_ARM64) += -fpic > >+endif > > cflags-$(CONFIG_ARM) := $(subst -pg,,$(KBUILD_CFLAGS)) \ > > -fno-builtin -fpic -mno-single-pic-base > > > >@@ -38,6 +41,9 @@ $(obj)/lib-%.o: $(srctree)/lib/%.c FORCE > > > > lib-$(CONFIG_EFI_ARMSTUB) += arm-stub.o fdt.o string.o random.o \ > > $(patsubst %.c,lib-%.o,$(arm-deps)) > >+ifeq ($(cc-name),clang) > >+CFLAGS_arm64-stub.o += -fno-pic > >+endif > > > > lib-$(CONFIG_ARM) += arm32-stub.o > > lib-$(CONFIG_ARM64) += arm64-stub.o > > > > NAK. > > This patch was labeled "HACK:" in our experimental tree. There's no > rhyme or reason to why this combination of -f[no-]pic flags > generates code without problematic relocations. It's inherently > fragile, and was only intended as a temporary workaround until I (or > someone more familiar with EFI) got a chance to revisit the problem. > > Unless the gcc CFLAGS are also an artifact of "mess with -f[no-]pic > until the compiler generates what you want", this doesn't belong > upstream. Sorry, I didn't realize it is that bad of a hack. Unfortunately I'm not very familiar with EFI either. I saw Ard did some work in this code related with relocation, maybe he can provide a pointer towards a better solution. Thanks Matthias