Received: by 2002:ad5:4acb:0:0:0:0:0 with SMTP id n11csp720081imw; Fri, 8 Jul 2022 10:26:06 -0700 (PDT) X-Google-Smtp-Source: AGRyM1tS+VcjkHWFYD9rYpgQsHY3pW+dOkhV/APLxwAUejTFdQDO82iHNqLPDAqXQIKMBmAR+RK3 X-Received: by 2002:a17:902:988b:b0:16b:fae3:fcd5 with SMTP id s11-20020a170902988b00b0016bfae3fcd5mr4736739plp.109.1657301166252; Fri, 08 Jul 2022 10:26:06 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1657301166; cv=none; d=google.com; s=arc-20160816; b=jMNAHwZ4DIVe25KiALfO1xkGzlpakHeNRzD6RvrWHE6io//ipK5wmEUliVHxJBpYTd 3CyO78jiZZSMB+bWt2izUdk/wm18kgbSYYtvs0fUkpqY0Bvko+23Sa2lEI1fyMbNXOll hiRbJxLnNivsMz7gb2aOyjiS3u6WEDz/pFCE5v5t/zI9OGs+mKpmaqJHXWbqARgnkApL K8eTkzrBXiD6nT/lDGPDmsc7lOpEpIupuv3PHvaWz6EKb2QFC5pICPiDYFrbb2Kz5YHa 4mgdJfZY8eLEZwQVb9WMiLwq1zYt7wS+9ku210rozegu51qAenWS7MFaIpjvrRNSo9BY iUkg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:user-agent:in-reply-to:content-transfer-encoding :content-disposition:mime-version:references:message-id:subject:cc :to:from:date:dkim-signature; bh=49oJnsyJpqJTvPk6o92RiUikbTHmfJ6rpWbEKHC4uck=; b=M+ccFqj53V5l0s24bkhs87iDk5j5znYC28K8LYd/obVCiR2XCSQR0A1qnjjr8uA+5R oYW1tZa3mBwm1STVptFnnqtUTdAXBgf+Yxu61VZHzPceoVG84zheRaXwN6ufRhhW41Ng Gd6hyDt+jrBdYBw8nB7/ABFnj9H+hRSzwXD6qOZh2FLIxMZHQBwxORqV+ZHgm3g8/LZQ hpNxDE5NvlY4Vzg5z+qCAYYN8+zlvvT4zRECHSmV/V7gnUKa2wyPt9m+a2KJjReVTGDS ci1lrShNTx+ze6TUZSMD61bXlJIUHzLHWuFII0v4vklLEfbCUA0HLO2T/p2fFN1LnOur /U3Q== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=mIS6t6kb; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 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 out1.vger.email (out1.vger.email. [2620:137:e000::1:20]) by mx.google.com with ESMTP id s13-20020aa78d4d000000b00528d8a633f2si4565482pfe.330.2022.07.08.10.25.52; Fri, 08 Jul 2022 10:26:06 -0700 (PDT) Received-SPF: pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 as permitted sender) client-ip=2620:137:e000::1:20; Authentication-Results: mx.google.com; dkim=pass header.i=@kernel.org header.s=k20201202 header.b=mIS6t6kb; spf=pass (google.com: domain of linux-kernel-owner@vger.kernel.org designates 2620:137:e000::1:20 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 S238537AbiGHROa (ORCPT + 99 others); Fri, 8 Jul 2022 13:14:30 -0400 Received: from lindbergh.monkeyblade.net ([23.128.96.19]:55040 "EHLO lindbergh.monkeyblade.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S238508AbiGHRO2 (ORCPT ); Fri, 8 Jul 2022 13:14:28 -0400 Received: from dfw.source.kernel.org (dfw.source.kernel.org [139.178.84.217]) by lindbergh.monkeyblade.net (Postfix) with ESMTPS id 13AE959271 for ; Fri, 8 Jul 2022 10:14:27 -0700 (PDT) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 8E3A1623A6 for ; Fri, 8 Jul 2022 17:14:26 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 9645BC341C0; Fri, 8 Jul 2022 17:14:25 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1657300465; bh=YexxORAIOe6/bznfuqOwteBKlaCjm36wg+GTYyj/hcE=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=mIS6t6kbGPEAeTQtbbRDMFrnQYTRmlXtaqvpvTt5+T2TPuJzn7VQU9OJpxefZ6giq 3/xMFA9UfGJ6bQTgP8KRLdJKz2t/Nh/PVO1YVb8WDwRPxspgXIWaN+EmHP2CHFMHXS 9QiGJww/PpKx1HbmXbRXosdQC/LXURoXWWeZfufMxX9vCiXpGWtswz+ezPi1vWTubo +cSmFAzXaKc4gj8WhF/eQrWG1qcRD9ZQBT23znWqLjdKgJwUDs7C4Lhj/uV3gAv+KN Uh7dbLAjuwP/V2BVi/3SEzgNX+ALLQVU1OhqQlpeSpnmW5wvLd8F98PK2jAVIfhz/v 0j+kt38zyvWGQ== Received: by pali.im (Postfix) id DBC7F7D1; Fri, 8 Jul 2022 19:14:22 +0200 (CEST) Date: Fri, 8 Jul 2022 19:14:22 +0200 From: Pali =?utf-8?B?Um9ow6Fy?= To: Arnd Bergmann Cc: Michael Ellerman , linuxppc-dev , Linux Kernel Mailing List Subject: Re: [PATCH] powerpc: e500: Fix compilation with gcc e500 compiler Message-ID: <20220708171422.mpbhb4ejarwnce6m@pali> References: <20220524093939.30927-1-pali@kernel.org> <20220702094405.tp7eo4df7fjvn2ng@pali> <8D562851-304F-4153-9194-426CC22B7FF2@ellerman.id.au> <20220704103951.nm4m4kpgnus3ucqo@pali> <20220704131358.fy3z7tjcmk2m6pfh@pali> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <20220704131358.fy3z7tjcmk2m6pfh@pali> User-Agent: NeoMutt/20180716 X-Spam-Status: No, score=-7.8 required=5.0 tests=BAYES_00,DKIMWL_WL_HIGH, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,RCVD_IN_DNSWL_HI, SPF_HELO_NONE,SPF_PASS,T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on lindbergh.monkeyblade.net Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Monday 04 July 2022 15:13:58 Pali Rohár wrote: > On Monday 04 July 2022 14:07:10 Arnd Bergmann wrote: > > On Mon, Jul 4, 2022 at 12:39 PM Pali Rohár wrote: > > > On Monday 04 July 2022 20:23:29 Michael Ellerman wrote: > > > > On 2 July 2022 7:44:05 pm AEST, "Pali Rohár" wrote: > > > > >On Tuesday 24 May 2022 11:39:39 Pali Rohár wrote: > > > > >> gcc e500 compiler does not support -mcpu=powerpc option. When it is > > > > >> specified then gcc throws compile error: > > > > >> > > > > >> gcc: error: unrecognized argument in option ‘-mcpu=powerpc’ > > > > >> gcc: note: valid arguments to ‘-mcpu=’ are: 8540 8548 native > > > > >> > > > > >> So do not set -mcpu=powerpc option when CONFIG_E500 is set. Correct option > > > > >> -mcpu=8540 for CONFIG_E500 is set few lines below in that Makefile. > > > > >> > > > > >> Signed-off-by: Pali Rohár > > > > >> Cc: stable@vger.kernel.org > > > > > > > > > >Michael, do you have any objections about this patch? > > > > > > > > I don't particularly like it :) > > > > > > > > From the discussion with Segher, it sounds like this is a problem with a specific build of gcc that you're using, not a general problem with gcc built with e500 support. > > > > > > Well, the "full" build of gcc for e500 cores with SPE does not support > > > -mcpu=powerpc option. So I think this is a general problem. I do not > > > think that this is "specific build" as this is the correct build of gcc > > > for these processors with e500 cores. > > > > > > "stripped". build of gcc without SPE support for e500 cores does not > > > have this problem... > > > > I can see a couple of problems with the CPU selection, but I don't think > > this is a major one, as nobody should be using those SPE compilers for > > building the kernel. Just use a modern powerpc-gcc build. > > The point is to use same compiler for building kernel as for the all > other parts of the system. > > I just do not see reason why for kernel it is needed to build completely > different toolchain and compiler. > > > > > Keying it off CONFIG_E500 means it will fix your problem, but not anyone else who has a different non-e500 compiler that also doesn't support -mcpu=powerpc (for whatever reason). > > > > > > > > So I wonder if a better fix is to use cc-option when setting -mcpu=powerpc. > > > > > > > > > > Comment for that code which adds -mpcu=powerpc says: > > > > > > they are needed to set a sane 32-bit cpu target for the 64-bit cross > > > compiler which may default to the wrong ISA. > > > > > > So I'm not sure how to handle this in other way. GCC uses -mpcu=8540 > > > option for specifying to compile code for e500 cores and seems that > > > -mcpu=8540 is supported by all e500 compilers... > > > > > > Few lines below is code > > > > > > CFLAGS-$(CONFIG_E500) += $(call cc-option,-mcpu=8540 -msoft-float,-mcpu=powerpc) > > > > > > which for e500 kernel builds user either -mcpu=8540 or -mcpu=powerpc > > > (probably as a fallback if -mcpu=8540 is not supported). > > > > The -mcpu=powerpc fallback can probably be skipped here, that must have been > > for compilers predating the addition of -mcpu=8540, and even the oldest ones > > support that now. > > Ok, makes sense. > > > > So for me it looks like that problematic code > > > > > > KBUILD_CFLAGS += -mcpu=powerpc > > > KBUILD_AFLAGS += -mcpu=powerpc > > > > > > needs to be somehow skipped when compiling for CONFIG_E500. > > >> My change which skips that code base on ifndef CONFIG_E500 should be > > > fine as when CONFIG_E500 is disabled it does nothing and when it is > > > enabled then code > > > > > > CFLAGS-$(CONFIG_E500) += $(call cc-option,-mcpu=8540 -msoft-float,-mcpu=powerpc) > > > > > > is called which sets -mcpu option suitable for e500. > > > > I think this part is indeed fishy, but adding another special case for E500 > > seems to take it in the wrong direction. > > > > Nick added this in 4bf4f42a2feb ("powerpc/kbuild: Set default generic > > machine type > > for 32-bit compile") as a compile-time fix to prevent the default target from > > getting used when the compiler supports both 64-bit and 32-bit. This is the > > right idea, but it's inconsistent to pass different flags depending on the type > > of toolchain, and it loses the more specific options. > > > > Another problem I see is that a kernel that is built for both E500 and E500MC > > uses -mcpu=e500mc and may not actually work on the older ones either > > (even with your patch). > > That is probably truth, -mcpu=8540 should have been chosen. (Anyway it > should have been called -mcpu=e500, no idea why gcc still name it 8540.) > > > I think what you actually want is to set one option for each of the > > possible CPU types: > > > > CFLAGS_CPU-$(CONFIG_PPC_BOOK3S_32) := -mcpu=powerpc > > CFLAGS_CPU-$(CONFIG_PPC_85xx) := -mcpu=8540 > > CFLAGS_CPU-$(CONFIG_PPC8xx) := -mcpu=860 > > CFLAGS_CPU-$(CONFIG_PPC44x) := -mcpu=440 > > CFLAGS_CPU-$(CONFIG_PPC40x) := -mcpu=405 > > ifdef CONFIG_CPU_LITTLE_ENDIAN > > CFLAGS_CPU-$(CONFIG_BOOK3S_64) := -mcpu=power8 > > else > > CFLAGS_CPU-$(CONFIG_BOOK3S_64) := -mcpu=power5 > > endif > > CFLAGS_CPU-$(CONFIG_BOOK3E_64) := -mcpu=powerpc64 > > Yes, this is something I would expect that in Makefile should be. So what about this change? diff --git a/arch/powerpc/Makefile b/arch/powerpc/Makefile index a0cd70712061..74a608b5796a 100644 --- a/arch/powerpc/Makefile +++ b/arch/powerpc/Makefile @@ -15,22 +15,7 @@ HAS_BIARCH := $(call cc-option-yn, -m32) # Set default 32 bits cross compilers for vdso and boot wrapper CROSS32_COMPILE ?= -ifeq ($(HAS_BIARCH),y) -ifeq ($(CROSS32_COMPILE),) -ifdef CONFIG_PPC32 -# These options will be overridden by any -mcpu option that the CPU -# or platform code sets later on the command line, but they are needed -# to set a sane 32-bit cpu target for the 64-bit cross compiler which -# may default to the wrong ISA. -KBUILD_CFLAGS += -mcpu=powerpc -KBUILD_AFLAGS += -mcpu=powerpc -endif -endif -endif - -ifdef CONFIG_PPC_BOOK3S_32 -KBUILD_CFLAGS += -mcpu=powerpc -endif +CFLAGS-$(CONFIG_PPC_BOOK3S_32) += -mcpu=powerpc # If we're on a ppc/ppc64/ppc64le machine use that defconfig, otherwise just use # ppc64_defconfig because we have nothing better to go on. @@ -163,17 +148,14 @@ CFLAGS-$(CONFIG_PPC32) += $(call cc-option, $(MULTIPLEWORD)) CFLAGS-$(CONFIG_PPC32) += $(call cc-option,-mno-readonly-in-sdata) -ifdef CONFIG_PPC_BOOK3S_64 ifdef CONFIG_CPU_LITTLE_ENDIAN -CFLAGS-$(CONFIG_GENERIC_CPU) += -mcpu=power8 -CFLAGS-$(CONFIG_GENERIC_CPU) += $(call cc-option,-mtune=power9,-mtune=power8) +CFLAGS-$(CONFIG_PPC_BOOK3S_64) += -mcpu=power8 +CFLAGS-$(CONFIG_PPC_BOOK3S_64) += $(call cc-option,-mtune=power9,-mtune=power8) else -CFLAGS-$(CONFIG_GENERIC_CPU) += $(call cc-option,-mtune=power7,$(call cc-option,-mtune=power5)) -CFLAGS-$(CONFIG_GENERIC_CPU) += $(call cc-option,-mcpu=power5,-mcpu=power4) -endif -else ifdef CONFIG_PPC_BOOK3E_64 -CFLAGS-$(CONFIG_GENERIC_CPU) += -mcpu=powerpc64 +CFLAGS-$(CONFIG_PPC_BOOK3S_64) += $(call cc-option,-mtune=power7,$(call cc-option,-mtune=power5)) +CFLAGS-$(CONFIG_PPC_BOOK3S_64) += $(call cc-option,-mcpu=power5,-mcpu=power4) endif +CFLAGS-$(CONFIG_PPC_BOOK3E_64) += -mcpu=powerpc64 ifdef CONFIG_FUNCTION_TRACER CC_FLAGS_FTRACE := -pg @@ -193,13 +175,8 @@ endif CFLAGS-$(CONFIG_E5500_CPU) += $(E5500_CPU) CFLAGS-$(CONFIG_E6500_CPU) += $(call cc-option,-mcpu=e6500,$(E5500_CPU)) -ifdef CONFIG_PPC32 -ifdef CONFIG_PPC_E500MC -CFLAGS-y += $(call cc-option,-mcpu=e500mc,-mcpu=powerpc) -else +CFLAGS-$(CONFIG_PPC_E500MC) += $(call cc-option,-mcpu=e500mc,-mcpu=powerpc) CFLAGS-$(CONFIG_E500) += $(call cc-option,-mcpu=8540 -msoft-float,-mcpu=powerpc) -endif -endif asinstr := $(call as-instr,lis 9$(comma)foo@high,-DHAVE_AS_ATHIGH=1) > But what to do with fallback value? > > > For the non-generic CPU types, there is also CONFIG_TARGET_CPU, > > and the list above could just get folded into that instead. > > > > Arnd