Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp1402148imu; Wed, 9 Jan 2019 18:04:07 -0800 (PST) X-Google-Smtp-Source: ALg8bN5YXGnh7DlVNd+SImKydKZqmbHBGlDE3+/YvzQl5PlAricHkWi5zqGeWNsm63ELPrTMlL/y X-Received: by 2002:a63:1321:: with SMTP id i33mr7768741pgl.380.1547085847574; Wed, 09 Jan 2019 18:04:07 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1547085847; cv=none; d=google.com; s=arc-20160816; b=BGBV9o3SBagK4dgnCNN16HS+zExIlvCy27ioDKvdHADm+Dp83yMa/YF474aXPJWlqa kk07cOLWGc7Kbpyn+yOG0/ksJ6kknCQf/gMHPHTUs2w1+eipscWivFWHPY9XweSmagby MJrcavz2kMIEkzILM4Wc8CMcr6/BHfOQVxG64DpO55FcXFKvSv95JfYK9Nw8iqK/3QLY S9wXZpiL5pCA8LUp7R+6Je7gwV7iXyL83t8Ljvxf59+0wgwlBgs7K8HhCF47oXSbU+Mo rC55llLgbef7HGytqHWo37GMDUUfXQ2e+60fAqH5Iuf6Ejc29cqOsDQ3bvBPDMotPQSu BjMg== 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:dkim-filter; bh=DKoDKvyK76QTjdnpbM9U16qtvJDLW6WtXVdR6h9x+Zk=; b=F+PXjaBWXZKaRIb5fGOgI1IMwdpBGEtv90+zZDVbyPKfbfHhGLb80BI591GYLDIYgD 3FzwfkwFqDvcr4PlR1MQPB+AZWT2CmxYXsCmFHjNvMS+zI/mSw54h93XG0LOwTj2X6ui 1wQLg1/WqEzWgikYetytw3s4nsq4BIrIWFscVF5DVrOrsHXnNB+Th25M/RKT5XymRqt7 cJ3qX6WJW8Uuq1gSVUHAyCAVJyNn4DESJWSeHjKLJagIH0japf10c2ic+0wtJYgFaHyM Gyj7yaH9BPXyRXrpIkaCz9lj/aTnbt6XjQ7xEZjsYMz38fvtRT6RnGYyMpT1S3k38+1+ M08w== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@nifty.com header.s=dec2015msa header.b=bF1Z7Je2; 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 Return-Path: Received: from vger.kernel.org (vger.kernel.org. [209.132.180.67]) by mx.google.com with ESMTP id r77si20323709pfa.186.2019.01.09.18.03.51; Wed, 09 Jan 2019 18:04:07 -0800 (PST) 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=@nifty.com header.s=dec2015msa header.b=bF1Z7Je2; 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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1726952AbfAJCBt (ORCPT + 99 others); Wed, 9 Jan 2019 21:01:49 -0500 Received: from conssluserg-01.nifty.com ([210.131.2.80]:41254 "EHLO conssluserg-01.nifty.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1726541AbfAJCBs (ORCPT ); Wed, 9 Jan 2019 21:01:48 -0500 Received: from mail-vs1-f47.google.com (mail-vs1-f47.google.com [209.85.217.47]) (authenticated) by conssluserg-01.nifty.com with ESMTP id x0A21Qco025112; Thu, 10 Jan 2019 11:01:26 +0900 DKIM-Filter: OpenDKIM Filter v2.10.3 conssluserg-01.nifty.com x0A21Qco025112 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nifty.com; s=dec2015msa; t=1547085687; bh=DKoDKvyK76QTjdnpbM9U16qtvJDLW6WtXVdR6h9x+Zk=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=bF1Z7Je2DXVZLDH76bNDxKmpcT7MDtiuZf9If13f9/q+2+HvV7hAmC41pMkRNHm9E GFZqxuPhKSLTbz5UUY8m91RQd+oj6uzaH83QQcziC+nT95LOBeZf8eDTibUsWo3UyF iZ6fWChmikR3hjL+S3sF+YRvVSYyCavVoO06fR9XySjOxy9Lw5N1UNjDaSfH6OPKOW uJgJRC8mARNBTWdbFi9uJ2vt55e8/rU7B82waUp1wyWryjD5PXswO49L3f8nPxiR16 MM5u4TgEtf66qMAXfrwrvSbx5WhzRUV90s52iegOlYRLIyQIx3n8JGEBgKfZ/ntVGP a3POe3yfW0mVw== X-Nifty-SrcIP: [209.85.217.47] Received: by mail-vs1-f47.google.com with SMTP id x64so6062548vsa.5; Wed, 09 Jan 2019 18:01:26 -0800 (PST) X-Gm-Message-State: AJcUukfjXbl3opNcQuCcAzJ9HOSQq/FyIM61Do4cfRUu1zkDbyqeVxzx rCq0VXLYDN82g0/0RyrKBDAiE4+XlqQWglFy9tI= X-Received: by 2002:a67:a858:: with SMTP id r85mr3391514vse.215.1547085685569; Wed, 09 Jan 2019 18:01:25 -0800 (PST) MIME-Version: 1.0 References: <20190109231539.24613-1-paul.burton@mips.com> In-Reply-To: <20190109231539.24613-1-paul.burton@mips.com> From: Masahiro Yamada Date: Thu, 10 Jan 2019 11:00:49 +0900 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH] kbuild: Disable LD_DEAD_CODE_DATA_ELIMINATION with ftrace & GCC <= 4.7 To: Paul Burton Cc: "linux-kbuild@vger.kernel.org" , "linux-mips@vger.kernel.org" , "linux-kernel@vger.kernel.org" , Paul Burton , Geert Uytterhoeven , Nicholas Piggin , "stable@vger.kernel.org" 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 Thu, Jan 10, 2019 at 8:16 AM Paul Burton wrote: > > When building using GCC 4.7 or older, -ffunction-sections & the -pg flag > used by ftrace are incompatible. This causes warnings or build failures > (where -Werror applies) such as the following: > > arch/mips/generic/init.c: > error: -ffunction-sections disabled; it makes profiling impossible > > This used to be taken into account by the ordering of calls to cc-option > from within the top-level Makefile, which was introduced by commit > 90ad4052e85c ("kbuild: avoid conflict between -ffunction-sections and > -pg on gcc-4.7"). Unfortunately this was broken when the > CONFIG_LD_DEAD_CODE_DATA_ELIMINATION cc-option check was moved to > Kconfig in commit e85d1d65cd8a ("kbuild: test dead code/data elimination > support in Kconfig"), because the flags used by this check no longer > include -pg. > > Fix this by not allowing CONFIG_LD_DEAD_CODE_DATA_ELIMINATION to be > enabled at the same time as ftrace/CONFIG_FUNCTION_TRACER when building > using GCC 4.7 or older. > > Signed-off-by: Paul Burton > Fixes: e85d1d65cd8a ("kbuild: test dead code/data elimination support in Kconfig") > Reported-by: Geert Uytterhoeven > Cc: Masahiro Yamada > Cc: Nicholas Piggin > Cc: stable@vger.kernel.org # v4.19+ > --- > init/Kconfig | 1 + > 1 file changed, 1 insertion(+) > > diff --git a/init/Kconfig b/init/Kconfig > index d47cb77a220e..c787f782148d 100644 > --- a/init/Kconfig > +++ b/init/Kconfig > @@ -1124,6 +1124,7 @@ config LD_DEAD_CODE_DATA_ELIMINATION > bool "Dead code and data elimination (EXPERIMENTAL)" > depends on HAVE_LD_DEAD_CODE_DATA_ELIMINATION > depends on EXPERT > + depends on !FUNCTION_TRACER || !CC_IS_GCC || GCC_VERSION >= 40800 > depends on $(cc-option,-ffunction-sections -fdata-sections) > depends on $(ld-option,--gc-sections) > help Thanks for the fix. I prefer this explicit 'depends on'. Relying on the order of $(call cc-option, ...) in Makefile is fragile. We raise the compiler minimum version from time to time. So, this 'depends on' will eventually go away in the future. BTW, which one do you think more readable? depends on !FUNCTION_TRACER || !CC_IS_GCC || GCC_VERSION >= 40800 OR depends on !(FUNCTION_TRACER && CC_IS_GCC && GCC_VERSION < 40800) -- Best Regards Masahiro Yamada