Received: by 2002:a05:6a10:206:0:0:0:0 with SMTP id 6csp24524pxj; Thu, 13 May 2021 19:46:39 -0700 (PDT) X-Google-Smtp-Source: ABdhPJzL5iPer+c4HzDmZCXDE2mGHBQj90OvMRQltYqhZzKM9yzZmie9WS8NAgni5HMRQ1q76OlZ X-Received: by 2002:a17:906:1311:: with SMTP id w17mr48018590ejb.182.1620960398980; Thu, 13 May 2021 19:46:38 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1620960398; cv=none; d=google.com; s=arc-20160816; b=PoDSSzWvkMKKFzXK+O8k+FK+EZpwhmhZfUOLwy4DWJ5G3x76CgI9hgj7NtPC6TDQPG NCd/L8xxmpb1IKAd6kV9mdj6O43cDaX0yIHwpZ2h/wcpBiOUlJ5atvG6BdkSvZ5UxLPI VTXi64d0X2B2EvhNR9BatgmjgN356Sx9lu7UuDKduQoHHFH1ooE94ERZN7mhK6jlkSHG ylwJNE9Gy0Wz2+vGz8NXRz52ihSmNJf0YkfQ5ze4bzcu7EQdEzz0V+9HIgGG6isSv0Dc 0/uzlZDcQjtlStNM+X/UfIUPDjrfnJRbyp7kWhYpdYiVDTJdcIQdyMHwe1jd5XOa00Dx nVzg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:cc:to:subject:message-id:date:from:in-reply-to :references:mime-version:dkim-signature:dkim-filter; bh=DVvuxt/F2VXaZ9qg0AYDMtDw08pty3tYij5WhoLhi5g=; b=zlgrI0By6tgxOD37bKl+rePBynLTG6CCE/937oebOAflKSb1NcfcN7IvQPPf14RWUO ft0hz3p65O3eQ/kV7PZbny9WCQUe5VwesboLVz9/+KjqBs6E+LMcqJTeLh9UjcrhO97r vOzUbvfMYzkeeyC11cUfk6g42xmEJjZhITctX6pIoLXB4VH1gObMmD2rZYOgJ2g7E4Ck I8ag6NIbt1MefNfN4T4+heyh/oE3Q2RlOSSjo2v1gZ0XvS8zSHYdrSUwkLk4JH800oyk aGplgL4yWgboNMypdxKZQiUWlQqEU5gTCDanuSbclu9aPTkEXQTm2Qq7GQydkqF0HH4B sjpw== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@nifty.com header.s=dec2015msa header.b=gx32ilFS; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id y14si4592133edc.72.2021.05.13.19.46.15; Thu, 13 May 2021 19:46:38 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) client-ip=23.128.96.18; Authentication-Results: mx.google.com; dkim=pass header.i=@nifty.com header.s=dec2015msa header.b=gx32ilFS; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 23.128.96.18 as permitted sender) smtp.mailfrom=linux-kernel-owner@vger.kernel.org; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=kernel.org Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S229701AbhENCom (ORCPT + 99 others); Thu, 13 May 2021 22:44:42 -0400 Received: from conssluserg-01.nifty.com ([210.131.2.80]:49115 "EHLO conssluserg-01.nifty.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S229459AbhENCom (ORCPT ); Thu, 13 May 2021 22:44:42 -0400 Received: from mail-pg1-f169.google.com (mail-pg1-f169.google.com [209.85.215.169]) (authenticated) by conssluserg-01.nifty.com with ESMTP id 14E2hA87030905; Fri, 14 May 2021 11:43:10 +0900 DKIM-Filter: OpenDKIM Filter v2.10.3 conssluserg-01.nifty.com 14E2hA87030905 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nifty.com; s=dec2015msa; t=1620960190; bh=DVvuxt/F2VXaZ9qg0AYDMtDw08pty3tYij5WhoLhi5g=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=gx32ilFSrPZOgzKEh5xfrqGmgbxdNAIPFWkBvj1cuFTQS0hKYB4pL3oi435qEe/1I UhGKdRVSVyb3mXfThkMhVFzSk569aA4Bm/XoXz7FtG6xkqWaED61hCWeqD55Ua9pWF AQpuOnvEZxN+CGg8mYx12xD9mn7wcY/ChHectxviA+7hO/b9NvtFcxMuLjqbr7Aov2 jvnPLRpw+eqKFKO2DCDfscdpcwN6Z0K5jiHi/VaXdqTExzSp+oWmVgNUhbGqLETOqQ GHib2SkqhGVt7dfmBPX4V+WfJ/sB7FQRBZKC3XQmSNMmyRKZsaMVoDhjapwUDMD5Pf +h3nd8CyVq+ng== X-Nifty-SrcIP: [209.85.215.169] Received: by mail-pg1-f169.google.com with SMTP id q15so18884875pgg.12; Thu, 13 May 2021 19:43:10 -0700 (PDT) X-Gm-Message-State: AOAM532YGLdqAk99euIWOSvuEdHXS37cFxuDApqUmwuNorGbSGdZuqMc klVvYUTlBm0lTKDE/XmgVehU4jvo+pkajuMFtXA= X-Received: by 2002:a63:a547:: with SMTP id r7mr44000108pgu.7.1620960189536; Thu, 13 May 2021 19:43:09 -0700 (PDT) MIME-Version: 1.0 References: <20210513115904.519912-1-aik@ozlabs.ru> In-Reply-To: From: Masahiro Yamada Date: Fri, 14 May 2021 11:42:32 +0900 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH kernel v3] powerpc/makefile: Do not redefine $(CPP) for preprocessor To: Nathan Chancellor Cc: Alexey Kardashevskiy , linuxppc-dev , Linux Kernel Mailing List , Linux Kbuild mailing list , clang-built-linux , Nick Desaulniers , Michal Marek , Michael Ellerman , Segher Boessenkool Content-Type: text/plain; charset="UTF-8" Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, May 14, 2021 at 3:59 AM Nathan Chancellor wrote: > > On 5/13/2021 4:59 AM, Alexey Kardashevskiy wrote: > > The $(CPP) (do only preprocessing) macro is already defined in Makefile. > > However POWERPC redefines it and adds $(KBUILD_CFLAGS) which results > > in flags duplication. Which is not a big deal by itself except for > > the flags which depend on other flags and the compiler checks them > > as it parses the command line. > > > > Specifically, scripts/Makefile.build:304 generates ksyms for .S files. > > If clang+llvm+sanitizer are enabled, this results in > > > > -emit-llvm-bc -fno-lto -flto -fvisibility=hidden \ > > -fsanitize=cfi-mfcall -fno-lto ... > > > > in the clang command line and triggers error: I do not know how to reproduce this for powerpc. Currently, only x86 and arm64 select ARCH_SUPPORTS_LTO_CLANG. Is this a fix for a potential issue? > > clang-13: error: invalid argument '-fsanitize=cfi-mfcall' only allowed with '-flto' > > > > This removes unnecessary CPP redefinition. Which works fine as in most > > place KBUILD_CFLAGS is passed to $CPP except > > arch/powerpc/kernel/vdso64/vdso(32|64).lds. To fix vdso, this does: > > 1. add -m(big|little)-endian to $CPP > > 2. add target to $KBUILD_CPPFLAGS as otherwise clang ignores -m(big|little)-endian if > > the building platform does not support big endian (such as x86). > > > > Signed-off-by: Alexey Kardashevskiy > > --- > > Changes: > > v3: > > * moved vdso cleanup in a separate patch > > * only add target to KBUILD_CPPFLAGS for CLANG > > > > v2: > > * fix KBUILD_CPPFLAGS > > * add CLANG_FLAGS to CPPFLAGS > > --- > > Makefile | 1 + > > arch/powerpc/Makefile | 3 ++- > > 2 files changed, 3 insertions(+), 1 deletion(-) > > > > diff --git a/Makefile b/Makefile > > index 15b6476d0f89..5b545bef7653 100644 > > --- a/Makefile > > +++ b/Makefile > > @@ -576,6 +576,7 @@ CC_VERSION_TEXT = $(subst $(pound),,$(shell $(CC) --version 2>/dev/null | head - > > ifneq ($(findstring clang,$(CC_VERSION_TEXT)),) > > ifneq ($(CROSS_COMPILE),) > > CLANG_FLAGS += --target=$(notdir $(CROSS_COMPILE:%-=%)) > > +KBUILD_CPPFLAGS += --target=$(notdir $(CROSS_COMPILE:%-=%)) > > You can avoid the duplication here by just doing: > > KBUILD_CPPFLAGS += $(CLANG_FLAGS) > > I am still not super happy about the flag duplication but I am not sure > I can think of a better solution. If KBUILD_CPPFLAGS are always included > when building .o files, maybe we should just add $(CLANG_FLAGS) to > KBUILD_CPPFLAGS instead of KBUILD_CFLAGS? Hmm, I think including --target=* in CPP flags is sensible, but not all CLANG_FLAGS are CPP flags. At least, -(no)-integrated-as is not a CPP flag. We could introduce a separate CLANG_CPP_FLAGS, but it would require more code changes... So, I do not have a strong opinion either way. BTW, another approach might be to modify the linker script. In my best guess, the reason why powerpc adding the endian flag to CPP is this line in arch/powerpc/kernel/vdso64/vdso64.lds.S #ifdef __LITTLE_ENDIAN__ OUTPUT_FORMAT("elf64-powerpcle", "elf64-powerpcle", "elf64-powerpcle") #else OUTPUT_FORMAT("elf64-powerpc", "elf64-powerpc", "elf64-powerpc") #endif You can use the CONFIG option to check the endian-ness. #ifdef CONFIG_CPU_BIG_ENDIAN OUTPUT_FORMAT("elf64-powerpc", "elf64-powerpc", "elf64-powerpc") #else OUTPUT_FORMAT("elf64-powerpcle", "elf64-powerpcle", "elf64-powerpcle") #endif All the big endian arches define CONFIG_CPU_BIG_ENDIAN. (but not all little endian arches define CONFIG_CPU_LITTLE_ENDIAN) So, #ifdef CONFIG_CPU_BIG_ENDIAN < big endian code > #else < little endian code > #endif works for all architectures. Only the exception is you cannot replace the one in uapi headers. arch/powerpc/include/uapi/asm/byteorder.h: #ifdef __LITTLE_ENDIAN__ since it is exported to userspace, where CONFIG options are not available. BTW, various flags are historically used. - CONFIG_CPU_BIG_ENDIAN / CONFIG_CPU_LITTLE_ENDIAN - __BIG_ENDIAN / __LITTLE_ENDIAN - __LITTLE_ENDIAN__ (powerpc only) __LITTLE_ENDIAN__ is defined by powerpc gcc and clang. My experiments... [1] powerpc-linux-gnu-gcc -> __BIG_ENDIAN__ is defined masahiro@grover:~$ echo | powerpc-linux-gnu-gcc -E -dM -x c - | grep ENDIAN #define __ORDER_LITTLE_ENDIAN__ 1234 #define __BIG_ENDIAN__ 1 #define __FLOAT_WORD_ORDER__ __ORDER_BIG_ENDIAN__ #define __ORDER_PDP_ENDIAN__ 3412 #define _BIG_ENDIAN 1 #define __BYTE_ORDER__ __ORDER_BIG_ENDIAN__ #define __VEC_ELEMENT_REG_ORDER__ __ORDER_BIG_ENDIAN__ #define __ORDER_BIG_ENDIAN__ 4321 [2] powerpc-linux-gnu-gcc + -mlittle-endian -> __LITTLE_ENDIAN__ is defined masahiro@grover:~$ echo | powerpc-linux-gnu-gcc -E -dM -x c - -mlittle-endian | grep ENDIAN #define __ORDER_LITTLE_ENDIAN__ 1234 #define _LITTLE_ENDIAN 1 #define __FLOAT_WORD_ORDER__ __ORDER_LITTLE_ENDIAN__ #define __ORDER_PDP_ENDIAN__ 3412 #define __LITTLE_ENDIAN__ 1 #define __BYTE_ORDER__ __ORDER_LITTLE_ENDIAN__ #define __VEC_ELEMENT_REG_ORDER__ __ORDER_LITTLE_ENDIAN__ #define __ORDER_BIG_ENDIAN__ 4321 [3] other arch gcc -> neither of them is defined masahiro@grover:~$ echo | gcc -E -dM -x c - | grep ENDIAN #define __ORDER_LITTLE_ENDIAN__ 1234 #define __FLOAT_WORD_ORDER__ __ORDER_LITTLE_ENDIAN__ #define __ORDER_PDP_ENDIAN__ 3412 #define __ORDER_BIG_ENDIAN__ 4321 #define __BYTE_ORDER__ __ORDER_LITTLE_ENDIAN__ masahiro@grover:~$ echo | arm-linux-gnueabihf-gcc -E -dM -x c - -mlittle-endian | grep ENDIAN #define __ORDER_LITTLE_ENDIAN__ 1234 #define __FLOAT_WORD_ORDER__ __ORDER_LITTLE_ENDIAN__ #define __ORDER_PDP_ENDIAN__ 3412 #define __BYTE_ORDER__ __ORDER_LITTLE_ENDIAN__ #define __ORDER_BIG_ENDIAN__ 4321 masahiro@grover:~$ echo | arm-linux-gnueabihf-gcc -E -dM -x c - -mbig-endian | grep ENDIAN #define __ORDER_LITTLE_ENDIAN__ 1234 #define __FLOAT_WORD_ORDER__ __ORDER_BIG_ENDIAN__ #define __ORDER_PDP_ENDIAN__ 3412 #define __ARM_BIG_ENDIAN 1 #define __BYTE_ORDER__ __ORDER_BIG_ENDIAN__ #define __ORDER_BIG_ENDIAN__ 4321 [4] Clang --target=powerpc-linux-gnu -> __BIG_ENDIAN__ is defined masahiro@grover:~$ echo | ~/tools/clang-latest/bin/clang -E --target=powerpc-linux-gnu -dM -x c - | grep ENDIAN #define _BIG_ENDIAN 1 #define __BIG_ENDIAN__ 1 #define __BYTE_ORDER__ __ORDER_BIG_ENDIAN__ #define __ORDER_BIG_ENDIAN__ 4321 #define __ORDER_LITTLE_ENDIAN__ 1234 #define __ORDER_PDP_ENDIAN__ 3412 [5] very recent Clang understands --target=powerpcle-linux-gnu --> __LITTLE_ENDIAN__ is defined masahiro@grover:~$ echo | ~/tools/clang-latest/bin/clang -E --target=powerpcle-linux-gnu -dM -x c - | grep ENDIAN #define _LITTLE_ENDIAN 1 #define __BYTE_ORDER__ __ORDER_LITTLE_ENDIAN__ #define __LITTLE_ENDIAN__ 1 #define __ORDER_BIG_ENDIAN__ 4321 #define __ORDER_LITTLE_ENDIAN__ 1234 #define __ORDER_PDP_ENDIAN__ 3412 [6] very recent Clang, --target=powerpc-linux-gnu + -mlittle-endian --> __LITTLE_ENDIAN__ is defined masahiro@grover:~$ echo | ~/tools/clang-latest/bin/clang -E --target=powerpc-linux-gnu -dM -x c - -mlittle-endian | grep ENDIAN #define _LITTLE_ENDIAN 1 #define __BYTE_ORDER__ __ORDER_LITTLE_ENDIAN__ #define __LITTLE_ENDIAN__ 1 #define __ORDER_BIG_ENDIAN__ 4321 #define __ORDER_LITTLE_ENDIAN__ 1234 #define __ORDER_PDP_ENDIAN__ 3412 [7] Clang, target with little endian only , -mbig-endian is ignored masahiro@grover:~$ echo | clang -E -dM -x c - | grep ENDIAN #define __BYTE_ORDER__ __ORDER_LITTLE_ENDIAN__ #define __LITTLE_ENDIAN__ 1 #define __ORDER_BIG_ENDIAN__ 4321 #define __ORDER_LITTLE_ENDIAN__ 1234 #define __ORDER_PDP_ENDIAN__ 3412 masahiro@grover:~$ echo | clang -E -dM -x c - -mbig-endian | grep ENDIAN #define __BYTE_ORDER__ __ORDER_LITTLE_ENDIAN__ #define __LITTLE_ENDIAN__ 1 #define __ORDER_BIG_ENDIAN__ 4321 #define __ORDER_LITTLE_ENDIAN__ 1234 #define __ORDER_PDP_ENDIAN__ 3412 -- Best Regards Masahiro Yamada