Received: by 2002:a25:ad19:0:0:0:0:0 with SMTP id y25csp8138213ybi; Tue, 23 Jul 2019 03:29:06 -0700 (PDT) X-Google-Smtp-Source: APXvYqwCIQ7CmfC05zsAvKan/TZl8fKUkJ9Dud46X9rd06tNbJpHRg0caP90Ce+JGxYetaOQu/F/ X-Received: by 2002:a17:902:da4:: with SMTP id 33mr73179074plv.209.1563877745937; Tue, 23 Jul 2019 03:29:05 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1563877745; cv=none; d=google.com; s=arc-20160816; b=hwDFGSRvUk+rr5HbHu0hEZWnMpn8SjPv0tHZ+8cE+Q1L/ZSfgqk0drXH6wCtpqyQQx Y11vYAJ6l0wlM1NQDUWGxKUw18Smk2P/hwAn4n8zBZJQ2025NceSBYXeC3u5+MNy3cUF coTbEnYA+6j+xpaeDf/LNXtXboJyoEBTr3CI8+AGfDAU0a5IRon2IxxB7HzM7HyWIQIa /CEv8PD3M45h9b3oTpVUGXNtGd//UmsIkPLhFRtWCRD1AkD+ckSFnVFN//xi8JU47daQ Ul2Nqqg0bW4fOOx51pV025409aLZkLKy0cTSO3RLx2gVo4SPEJh8Nsz+rFV2QLMkNXsH SdDg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:cc:to:subject:message-id:date:from :in-reply-to:references:mime-version:dkim-signature; bh=JWzObsdwU3i63gvAqqM5ECXti3xb+XhH33+pC1nlaaE=; b=rRFpb1WoqeclpiJVxC1fXLq+MP/CdG8Zd6nmUxolpAJxTeGCLrS9KZd4GKkSeQzxi2 eT/dqGyO9M4OIKD3fZmxlqqOS2UE4ytxn0BDe00rCdjzwdNpFLRv5pyLu4Abe8UjSAlv obMwvJN7zF7svTIqICUfYF1aL37i2gPVk9n4FqZUBFmsEbx67lghh8gNgk8TMJtgv6tX mGcICaUbc9dxwD8WKaiHojk/CK5osUoAzicNhFTMdR9w7htl9BtkSF5HE4DUQHKxpy5z IB6mzD1f+mi6V8KmquwwB3fvFhjVQQlNC5Qh6D+ykT8/4dJijsL8jC/yMyTh3kHR+Cpf DMBw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=uY2n8ftA; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id u17si12099295pgn.387.2019.07.23.03.28.50; Tue, 23 Jul 2019 03:29:05 -0700 (PDT) Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67; Authentication-Results: mx.google.com; dkim=pass header.i=@google.com header.s=20161025 header.b=uY2n8ftA; spf=pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=REJECT sp=REJECT dis=NONE) header.from=google.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1733104AbfGVW75 (ORCPT + 99 others); Mon, 22 Jul 2019 18:59:57 -0400 Received: from mail-io1-f66.google.com ([209.85.166.66]:36907 "EHLO mail-io1-f66.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728414AbfGVW74 (ORCPT ); Mon, 22 Jul 2019 18:59:56 -0400 Received: by mail-io1-f66.google.com with SMTP id q22so77701272iog.4 for ; Mon, 22 Jul 2019 15:59:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=JWzObsdwU3i63gvAqqM5ECXti3xb+XhH33+pC1nlaaE=; b=uY2n8ftAPZVkAr8jdXWBsvcA8yE2U1CfjtybqA2v1jcwqs41Rc5uWFaGUn8oPnRXaX 3lfZTk36mp9FamG+/DoyegTCUAwZSZzYFBBhFjtXWGcaBzThO2TQSdiwihiIBMXW/4Bh OyNV8TZnwhmrWcqfgwn6lLrY49qviOAuTzMEMw1ai8KBzKf4Hb90sDAXpnFAFZGlvq6Z Gcy11kj1ZRl+XlYxCYZaQCFUfG266OQOPGCqPlxSKXFf5NS4hIQKQWJLxTk/FZZmkjKq GluMQ/svUi8OOMHmTlk/Nl24kVdeYwQYcmD/C9fLaJlyekSE24i/n1i/VDnmljBh/aHi fsmQ== 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=JWzObsdwU3i63gvAqqM5ECXti3xb+XhH33+pC1nlaaE=; b=VSXbsiFxsMixPWVzoflzDraGQbzcFQFmNxf2l6EF0h72Mn7kaDfNqhlAZXHkK2A33e MzQwKgLEW4zVxEVNEekUZL09HibmQ9tR4Mo+Cj493oNJu6vuiWFNgKNPrjVgyK7gdw4w JyXLd8M9uKqrdzoR+uCy+ndjBH3tg5eoVsS9msoJakww3hbmfEb3TgBeilEpgiE5KT9H MZYfVFHZzyMrLuozcmAftTC/1lZlBK4Q/upDSouFPABuOr4p2l2sQ7KhZtlyTYHPMkFQ NQT+aQKb7axDvFXqUxFkj66bMrJGvqKXOpdiT7AdG3+YDWorCjcVv9okw8Pif3ExYtBa 7mFQ== X-Gm-Message-State: APjAAAV5P59YkyT4UaTepvwnuuaKTYxjH6+hNWOfc+RLVxxZlaT0Fp6W OMzDCta3A6QKzUqNqzp3nOpY1KgEa339ah51+HHA3Q== X-Received: by 2002:a02:ad15:: with SMTP id s21mr78069681jan.47.1563836395727; Mon, 22 Jul 2019 15:59:55 -0700 (PDT) MIME-Version: 1.0 References: <20190722213250.238685-1-ndesaulniers@google.com> <20190722213250.238685-2-ndesaulniers@google.com> In-Reply-To: From: Vaibhav Rustagi Date: Mon, 22 Jul 2019 15:59:44 -0700 Message-ID: Subject: Re: [PATCH v2 2/2] x86/purgatory: use CFLAGS_REMOVE rather than reset KBUILD_CFLAGS To: Nick Desaulniers Cc: Thomas Gleixner , Ingo Molnar , Borislav Petkov , Peter Zijlstra , clang-built-linux , "H. Peter Anvin" , "maintainer:X86 ARCHITECTURE (32-BIT AND 64-BIT)" , LKML 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 Mon, Jul 22, 2019 at 3:10 PM Nick Desaulniers wrote: > > On Mon, Jul 22, 2019 at 2:33 PM Nick Desaulniers > wrote: > > > > KBUILD_CFLAGS is very carefully built up in the top level Makefile, > > particularly when cross compiling or using different build tools. > > Resetting KBUILD_CFLAGS via := assignment is an antipattern. > > > > The comment above the reset mentions that -pg is problematic. Other > > Makefiles like arch/x86/xen/vdso/Makefile use > > `CFLAGS_REMOVE_file.o = -pg` when CONFIG_FUNCTION_TRACER is set. Prefer > > that pattern to wiping out all of the important KBUILD_CFLAGS then > > manually having to re-add them. > > > > Fixes: 8fc5b4d4121c ("purgatory: core purgatory functionality") > > Reported-by: Vaibhav Rustagi > > Suggested-by: Peter Zijlstra > > Signed-off-by: Nick Desaulniers > > --- > > Rather than manually add -mno-sse, -mno-mmx, -mno-sse2, prefer to filter > > -pg flags. > > > > arch/x86/purgatory/Makefile | 12 +++++++----- > > 1 file changed, 7 insertions(+), 5 deletions(-) > > > > diff --git a/arch/x86/purgatory/Makefile b/arch/x86/purgatory/Makefile > > index 91ef244026d2..56bcabca283f 100644 > > --- a/arch/x86/purgatory/Makefile > > +++ b/arch/x86/purgatory/Makefile > > @@ -20,11 +20,13 @@ KCOV_INSTRUMENT := n > > > > # Default KBUILD_CFLAGS can have -pg option set when FTRACE is enabled. That > > # in turn leaves some undefined symbols like __fentry__ in purgatory and not > > -# sure how to relocate those. Like kexec-tools, use custom flags. > > - > > -KBUILD_CFLAGS := -fno-strict-aliasing -Wall -Wstrict-prototypes -fno-zero-initialized-in-bss -fno-builtin -ffreestanding -c -Os -mcmodel=large > > -KBUILD_CFLAGS += -m$(BITS) > > Is purgatory/kexec supported for CONFIG_X86_32? Should I be keeping > `-m$(BITS)`? arch/x86/purgatory/Makefile mentions > `setup-x86_$(BITS).o` which I assume is broken as there is no > arch/x86/purgatory/setup-x86_32.S? > > > -KBUILD_CFLAGS += $(call cc-option,-fno-PIE) > > +# sure how to relocate those. > > +ifdef CONFIG_FUNCTION_TRACER > > +CFLAGS_REMOVE_sha256.o = -pg > > +CFLAGS_REMOVE_purgatory.o = -pg > > +CFLAGS_REMOVE_string.o = -pg > > +CFLAGS_REMOVE_kexec-purgatory.o = -pg > > +endif > > The changes suggested will cause undefined symbols while loading the new kernel. On doing 'nm purgatory.ro', I found below undefined symbols: U bmcp U __stack_chk_fail > > $(obj)/purgatory.ro: $(PURGATORY_OBJS) FORCE > > $(call if_changed,ld) > > -- > > 2.22.0.657.g960e92d24f-goog > > > > > -- > Thanks, > ~Nick Desaulniers