Received: by 2002:ad5:474a:0:0:0:0:0 with SMTP id i10csp152619imu; Thu, 10 Jan 2019 20:34:49 -0800 (PST) X-Google-Smtp-Source: ALg8bN5om2u+cLatA3h8f8X0CFKDGBIPTWPPqQhuwuOW8inkOi+UJpETkQZ7MpgPckRZtkcHf5Lq X-Received: by 2002:a17:902:82c2:: with SMTP id u2mr13144686plz.110.1547181289712; Thu, 10 Jan 2019 20:34:49 -0800 (PST) ARC-Seal: i=1; a=rsa-sha256; t=1547181289; cv=none; d=google.com; s=arc-20160816; b=oM0cRu9cKJz7OfR/KAfB0eKa+alMkDmWmlh2IlLhAUk7HLuB47ewHmpkRUzhFjdysk 3Upz5EPCE9O9azgNbYktoHTl4YWvBz0tfMz0sb6EsXPD+onMjrZpm64eWgEiK1LjJRpI HNy18mmWsWHlrzjJwHVPd6dp8UmUvpPa+KI3kQK/B+n22o3kodFrIZANaXNVocjRiAY5 rUAjgbcv8j/hKlprcKsVr2KGX9Ps92S3a6/ZIq6mwWyBYJkMgUUeRe+phsnrgi6ae+tc y8b4tET36SG/Iip/I8GSaFp1HnYOE1SZ0WN9xHNuVUOxXt4r2b+ds91x9XbOvx+Shq5X s4dw== 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=42GLpL/gpsKXFu8DqqjKXktpxexfEsj5sSrDCB8KNK0=; b=U0/HlpwDualh/JyjTNyVjsIu1MHpxPvo7qeFBkKYvCU9YykrHRVQTgs3h+V++hva3o VjB2DVKh63QCMDJE0qIpfQvgIvgTFJ3OhkId+wsZNN+lTuqC6axvD8hwmRHPBPsrhRKh r94Js+nPdgcWzRbYqOhF+LtN3GQsn0cRNbM4VMbocgSgbAxe6Z4YXtJhuEUVjLrT3Djw LdqwEB/NAqekKOinpr+vt6xl5TkKFUIH8yot8h1zwqHkhPfPSKUuC0X3b5u9o7XUXOfu TEKks2OrdyFONkVQbTH6Ik/zhtmQClsk4Sb3uSIfAyh0kYzAAwiTIJ4rxqYBDpcsCAb3 helg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@nifty.com header.s=dec2015msa header.b=zkBlk2QN; 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 b63si76365878pfa.250.2019.01.10.20.34.34; Thu, 10 Jan 2019 20:34:49 -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=zkBlk2QN; 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 S1729762AbfAKCQH (ORCPT + 99 others); Thu, 10 Jan 2019 21:16:07 -0500 Received: from conssluserg-06.nifty.com ([210.131.2.91]:41450 "EHLO conssluserg-06.nifty.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728083AbfAKCQG (ORCPT ); Thu, 10 Jan 2019 21:16:06 -0500 X-Greylist: delayed 87258 seconds by postgrey-1.27 at vger.kernel.org; Thu, 10 Jan 2019 21:16:04 EST Received: from mail-vs1-f42.google.com (mail-vs1-f42.google.com [209.85.217.42]) (authenticated) by conssluserg-06.nifty.com with ESMTP id x0B2FwTH004798; Fri, 11 Jan 2019 11:15:59 +0900 DKIM-Filter: OpenDKIM Filter v2.10.3 conssluserg-06.nifty.com x0B2FwTH004798 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nifty.com; s=dec2015msa; t=1547172959; bh=42GLpL/gpsKXFu8DqqjKXktpxexfEsj5sSrDCB8KNK0=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=zkBlk2QNc9mPtufMq/iEjn53cFumIq9wAjcRocCCI8RgPJoM9H06ehv9oHlliijj2 VqbqumDlCzSiTikRTbTfXThbA1amJn6fVjQnzAh8FhuCJy+dbuR8foocn623SuGKRX PalZQ9tPvDVjPUXv2HPH1v+ZejrZ3xVhpWf9rhS3BrjhBQeLY6sSG2wKXnmRtszfc/ YL/DBjeigJncwvGX4uRR1hnd16PS13DLbf1mTYjxP9mBx+pBhSIMi15uDm44DhLtQc 1Ohw/ys088tXIuII3zV3ZpdyHtKu9m8Q/qo9b7sx5aC+PVGWtzsdWjjdleGkBeck5e ZoPD9AFKyPYJw== X-Nifty-SrcIP: [209.85.217.42] Received: by mail-vs1-f42.google.com with SMTP id n10so8296918vso.13; Thu, 10 Jan 2019 18:15:59 -0800 (PST) X-Gm-Message-State: AJcUukcCNanyw0qj2F0puWErTvP8UrXQOTGMU/FU3HZpL6lZVMtlfwNH D0hCRDXzNEa6pGWFfdKHByFn3H+ZI2yHA1kZqUo= X-Received: by 2002:a67:385a:: with SMTP id f87mr5196361vsa.179.1547172958102; Thu, 10 Jan 2019 18:15:58 -0800 (PST) MIME-Version: 1.0 References: <20190109231539.24613-1-paul.burton@mips.com> <20190110181106.otlwmiznvq2l67iv@pburton-laptop> In-Reply-To: <20190110181106.otlwmiznvq2l67iv@pburton-laptop> From: Masahiro Yamada Date: Fri, 11 Jan 2019 11:15:22 +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 Fri, Jan 11, 2019 at 3:11 AM Paul Burton wrote: > > Hi Masahiro, > > On Thu, Jan 10, 2019 at 11:00:49AM +0900, Masahiro Yamada wrote: > > 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) > > Thanks - yes I agree it's nice that this is more explicit than the > ordering we previously relied upon. > > I personally don't mind either of the 2 options above - let me know if > you'd like me to submit a v2 using your second option. > > Thanks, > Paul Personally, I slightly prefer this: depends on !(FUNCTION_TRACER && CC_IS_GCC && GCC_VERSION < 40800) It is more consistent with your patch title: "Disable LD_DEAD_CODE_DATA_ELIMINATION with ftrace & GCC <= 4.7" May I ask v2? -- Best Regards Masahiro Yamada