Received: by 2002:a25:5b86:0:0:0:0:0 with SMTP id p128csp453596ybb; Thu, 28 Mar 2019 06:00:57 -0700 (PDT) X-Google-Smtp-Source: APXvYqzY/H25XdUa5DyTkJCpGktZoe5dF8pMHXvaoto8fcHJywhgqReShnYN6hMxNDlhjbicoDNE X-Received: by 2002:a63:f74c:: with SMTP id f12mr39505498pgk.124.1553778056961; Thu, 28 Mar 2019 06:00:56 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1553778056; cv=none; d=google.com; s=arc-20160816; b=XH3P0bzPm7HmMSUNf2LpsMSXiavJ0d9hYiTOKn4PqadhRXuWgbn9ECIIQii8OKdpEI yhVCtbGJSfiRNSJjTLYeur+OWJCCRQsZkAjkoMmLFtgay2/Yp+jA7jMcOHZOkghNXRYU Ay/lM2CIWfgWH/H3bQGf6ig7XJAFkciuFh2DP28L1N6tzqyA9cfITKLmDB9SOfXhIlkq RPsIEbtWui3zso8m+sH7uUBlulFdt+5H9uSKCemsDkzxQgNVgeQlQvNnC977a1MOn+LC 6VXLocedvgwsI15MdeucwY35J18REbUHLOUdUkdbJKki850j8B4lrReiP/R4HmuVscpM /xbg== 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=iNmNHPxummQG0NGAnAG9Kb2w/4+4tPoyHR3WrxALJPQ=; b=zeA9B121U8hKDhmIskHGoKH0M/0Z3r20fnZDTqBcrrE1PxGr6LezfpFFyxp10KTqGG qtnnH3bPi92SLi4t45LwcsRdU7YStpmkKPqwEGzzfg7i0lpQLOdlovEgaC7l8RMWh1h+ tdOUIyvfUNdTqGxdJ6YfAIBriPIypw6GmmJZDQizEEqPDY4LCl+gu8dHVstZpQ/5Vc+r 0Oz5Aj2A+HBW9TdtbYoWY+PKGXTUvYBk2AZZb0I77jQnYJxC+6wJM0JvnUMHrFXeJY8f cw/MubVWIqFrktC9H7JadkqnXmimAHHLm7XQIw/NDI4uGYFecGoRNvctZIDt/SKtrS/o Kgqg== ARC-Authentication-Results: i=1; mx.google.com; dkim=pass header.i=@nifty.com header.s=dec2015msa header.b="0HS/QlZp"; 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 d68si18713655pfg.83.2019.03.28.06.00.38; Thu, 28 Mar 2019 06:00:56 -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=@nifty.com header.s=dec2015msa header.b="0HS/QlZp"; 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 S1727140AbfC1M6U (ORCPT + 99 others); Thu, 28 Mar 2019 08:58:20 -0400 Received: from conssluserg-04.nifty.com ([210.131.2.83]:28165 "EHLO conssluserg-04.nifty.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1725816AbfC1M6U (ORCPT ); Thu, 28 Mar 2019 08:58:20 -0400 Received: from mail-vk1-f170.google.com (mail-vk1-f170.google.com [209.85.221.170]) (authenticated) by conssluserg-04.nifty.com with ESMTP id x2SCw7cc019683; Thu, 28 Mar 2019 21:58:08 +0900 DKIM-Filter: OpenDKIM Filter v2.10.3 conssluserg-04.nifty.com x2SCw7cc019683 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=nifty.com; s=dec2015msa; t=1553777888; bh=iNmNHPxummQG0NGAnAG9Kb2w/4+4tPoyHR3WrxALJPQ=; h=References:In-Reply-To:From:Date:Subject:To:Cc:From; b=0HS/QlZprPavqjj2dwJ/CgToYMLqCJd6WpcoYVoSwLzQZd3+QhtbYDqwtqSIvki11 /B12xMVuZJ6Kif2dEw+HroNHhlkk3p9dEnRGAcn0eL0orqPZ+lZFOfJo+0G+a4ciLD svkdc39eEHeXBUJX+dOPIs/AVfp4hgTlaqL0qCrcHuUImpW8Ko/IUAEI4d3stHR4B7 esIhK6Gxf3wOjh3ESeKChiQeUQgZvABTMSt7iayuslkVrp8af9wNG5/27tXrefgrBr ujQwquaOnMd2IehEyjcdV7wChtb3fKKyfqvekkxQaTMFibxfYD2Uo4xJXfDQh0lZYG Xy8T8N6qkeNig== X-Nifty-SrcIP: [209.85.221.170] Received: by mail-vk1-f170.google.com with SMTP id v187so4455637vkf.12; Thu, 28 Mar 2019 05:58:08 -0700 (PDT) X-Gm-Message-State: APjAAAWeMEFLfxmFDkh7lvdYocHcWwzs4uKM4/exXatda1V0I7oQbMpU PAq8ZfwhdH+cvEViU0WRI07ya9MjW6xW5hVUm5w= X-Received: by 2002:a1f:9350:: with SMTP id v77mr24780964vkd.84.1553777886929; Thu, 28 Mar 2019 05:58:06 -0700 (PDT) MIME-Version: 1.0 References: <20190325160438.8982-1-joe.lawrence@redhat.com> <20190326173308.GA26546@redhat.com> In-Reply-To: <20190326173308.GA26546@redhat.com> From: Masahiro Yamada Date: Thu, 28 Mar 2019 21:57:31 +0900 X-Gmail-Original-Message-ID: Message-ID: Subject: Re: [PATCH v2] kbuild: strip whitespace in cmd_record_mcount findstring To: Joe Lawrence Cc: Linux Kbuild mailing list , linuxppc-dev , Linux Kernel Mailing List , Michal Marek , Nicholas Piggin , Steven Rostedt 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 Hi Joe, On Wed, Mar 27, 2019 at 2:33 AM Joe Lawrence wrote: > > On Tue, Mar 26, 2019 at 02:29:47PM +0900, Masahiro Yamada wrote: > > On Tue, Mar 26, 2019 at 1:05 AM Joe Lawrence wrote: > > > > > > CC_FLAGS_FTRACE may contain trailing whitespace that interferes with > > > findstring. > > > > > > For example, commit 6977f95e63b9 ("powerpc: avoid -mno-sched-epilog on > > > GCC 4.9 and newer") introduced a change such that on my ppc64le box, > > > CC_FLAGS_FTRACE="-pg -mprofile-kernel ". (Note the trailing space.) > > > When cmd_record_mcount is now invoked, findstring fails as the ftrace > > > flags were found at very end of _c_flags, without the trailing space. > > > > > > _c_flags=" ... -pg -mprofile-kernel" > > > CC_FLAGS_FTRACE="-pg -mprofile-kernel " > > > ^ > > > findstring is looking for this extra space > > > > > > Remove the redundant whitespaces from CC_FLAGS_FTRACE in > > > cmd_record_mcount to avoid this problem. > > > > > > Fixes: 6977f95e63b9 ("powerpc: avoid -mno-sched-epilog on GCC 4.9 and newer"). > > > Signed-off-by: Joe Lawrence > > > --- > > > > > > Standard disclaimer: I'm not a kbuild expert, but this works around the > > > problem I reported where ftrace and livepatch self-tests were failing as > > > specified object files were not run through the recordmcount.pl script: > > > > > > ppc64le: ftrace self-tests and $(CC_FLAGS_FTRACE) broken? > > > https://lists.ozlabs.org/pipermail/linuxppc-dev/2019-March/187298.html > > > > > > scripts/Makefile.build | 8 ++++---- > > > 1 file changed, 4 insertions(+), 4 deletions(-) > > > > > > diff --git a/scripts/Makefile.build b/scripts/Makefile.build > > > index 2554a15ecf2b..74d402b5aa3c 100644 > > > --- a/scripts/Makefile.build > > > +++ b/scripts/Makefile.build > > > @@ -199,10 +199,10 @@ sub_cmd_record_mcount = perl $(srctree)/scripts/recordmcount.pl "$(ARCH)" \ > > > "$(if $(part-of-module),1,0)" "$(@)"; > > > recordmcount_source := $(srctree)/scripts/recordmcount.pl > > > endif # BUILD_C_RECORDMCOUNT > > > -cmd_record_mcount = \ > > > - if [ "$(findstring $(CC_FLAGS_FTRACE),$(_c_flags))" = \ > > > - "$(CC_FLAGS_FTRACE)" ]; then \ > > > - $(sub_cmd_record_mcount) \ > > > +cmd_record_mcount = \ > > > + if [ "$(findstring $(strip $(CC_FLAGS_FTRACE)),$(_c_flags))" = \ > > > + "$(strip $(CC_FLAGS_FTRACE))" ]; then \ > > > + $(sub_cmd_record_mcount) \ > > > fi > > > endif # CC_USING_RECORD_MCOUNT > > > endif # CONFIG_FTRACE_MCOUNT_RECORD > > > -- > > > 2.20.1 > > > > > > > > > > > I do not see a point in using the shell command here > > in the first place. > > > > Instead of adding crappy workarounds, > > I guess the following simple code should work: > > > > > > index 2554a15..5f13021 100644 > > --- a/scripts/Makefile.build > > +++ b/scripts/Makefile.build > > @@ -199,11 +199,8 @@ sub_cmd_record_mcount = perl > > $(srctree)/scripts/recordmcount.pl "$(ARCH)" \ > > "$(if $(part-of-module),1,0)" "$(@)"; > > recordmcount_source := $(srctree)/scripts/recordmcount.pl > > endif # BUILD_C_RECORDMCOUNT > > -cmd_record_mcount = \ > > - if [ "$(findstring $(CC_FLAGS_FTRACE),$(_c_flags))" = \ > > - "$(CC_FLAGS_FTRACE)" ]; then \ > > - $(sub_cmd_record_mcount) \ > > - fi > > +cmd_record_mcount = $(if $(findstring $(CC_FLAGS_FTRACE),$(_c_flags)),\ > > + $(sub_cmd_record_mcount)) > > endif # CC_USING_RECORD_MCOUNT > > endif # CONFIG_FTRACE_MCOUNT_RECORD > > > > Hi Masahiro, > > Agreed on the shell command ugliness, however I still think we need to > strip the search pattern here. With your suggestion: > > % rm -f kernel/trace/trace_selftest_dynamic.o > % make kernel/trace/trace_selftest_dynamic.o > CALL scripts/checksyscalls.sh > CALL scripts/atomic/check-atomics.sh > CC kernel/trace/trace_selftest_dynamic.o > > % eu-readelf --sections kernel/trace/trace_selftest_dynamic.o | grep mcount > (nothing) > > Adding it back as, as below, restores those sections and the self tests > work again. OK, confirmed. First, I was wondering why I could not reproduce this issue. Then, I found the reason was I was using the latest GNU Make compiled from the git source tree. I found the following commit: commit b90fabc8d6f34fb37d428dc0fb1b8b1951a9fbed Author: Paul Smith Date: Sat May 27 20:07:30 2017 -0400 * NEWS: Do not insert a space during '+=' if the value is empty. * doc/make.texi (Appending): Document this behavior. * variable.c (do_variable_definition): Only add a space if the variable value is not empty. * tests/scripts/variables/flavors: Test this behavior. diff --git a/NEWS b/NEWS index e60644a..6e2c5c6 100644 --- a/NEWS +++ b/NEWS @@ -29,6 +29,12 @@ http://sv.gnu.org/bugs/index.php?group=make&report_id=111&fix_release_id=108&set This was claimed to be fixed in 3.81, but wasn't, for some reason. To detect this change search for 'nocomment' in the .FEATURES variable. +* WARNING: Backward-incompatibility! + Previously appending using '+=' to an empty variable would result in a value + starting with a space. Now the initial space is only added if the variable + already contains some value. Similarly, appending an empty string does not + add a trailing space. + * The previous limit of 63 jobs under -jN on MS-Windows is now increased to 4095. That limit includes the subprocess started by the $(shell) function. Applied to linux-kbuild/fixes with additional comments. [Additional info by masahiro.yamada: This issue only happens in the released versions of GNU Make. CC_FLAGS_FTRACE will not contain the trailing space if you use the latest GNU Make, which contains commit b90fabc8d6f3 ("* NEWS: Do not insert a space during '+=' if the value is empty.") ] > Regards, > > -- Joe > > -->8-- -->8-- -->8-- -->8-- -->8-- -->8-- -->8-- -->8-- -->8-- -->8-- > > From 6a85e8ecf4179b3e80601a327ec43d8d49f0e3cd Mon Sep 17 00:00:00 2001 > From: Joe Lawrence > Date: Tue, 26 Mar 2019 10:50:28 -0400 > Subject: [PATCH v2] kbuild: strip whitespace in cmd_record_mcount findstring > > CC_FLAGS_FTRACE may contain trailing whitespace that interferes with > findstring. > > For example, commit 6977f95e63b9 ("powerpc: avoid -mno-sched-epilog on > GCC 4.9 and newer") introduced a change such that on my ppc64le box, > CC_FLAGS_FTRACE="-pg -mprofile-kernel ". (Note the trailing space.) > When cmd_record_mcount is now invoked, findstring fails as the ftrace > flags were found at very end of _c_flags, without the trailing space. > > _c_flags=" ... -pg -mprofile-kernel" > CC_FLAGS_FTRACE="-pg -mprofile-kernel " > ^ > findstring is looking for this extra space > > Remove the redundant whitespaces from CC_FLAGS_FTRACE in > cmd_record_mcount to avoid this problem. > > Suggested-by: Masahiro Yamada (refactoring) > Fixes: 6977f95e63b9 ("powerpc: avoid -mno-sched-epilog on GCC 4.9 and newer"). > Signed-off-by: Joe Lawrence > --- > scripts/Makefile.build | 7 ++----- > 1 file changed, 2 insertions(+), 5 deletions(-) > > diff --git a/scripts/Makefile.build b/scripts/Makefile.build > index 2554a15ecf2b..76ca30cc4791 100644 > --- a/scripts/Makefile.build > +++ b/scripts/Makefile.build > @@ -199,11 +199,8 @@ sub_cmd_record_mcount = perl $(srctree)/scripts/recordmcount.pl "$(ARCH)" \ > "$(if $(part-of-module),1,0)" "$(@)"; > recordmcount_source := $(srctree)/scripts/recordmcount.pl > endif # BUILD_C_RECORDMCOUNT > -cmd_record_mcount = \ > - if [ "$(findstring $(CC_FLAGS_FTRACE),$(_c_flags))" = \ > - "$(CC_FLAGS_FTRACE)" ]; then \ > - $(sub_cmd_record_mcount) \ > - fi > +cmd_record_mcount = $(if $(findstring $(strip $(CC_FLAGS_FTRACE)),$(_c_flags)), \ > + $(sub_cmd_record_mcount)) > endif # CC_USING_RECORD_MCOUNT > endif # CONFIG_FTRACE_MCOUNT_RECORD > > -- > 2.20.1 > -- Best Regards Masahiro Yamada