Received: by 2002:a25:683:0:0:0:0:0 with SMTP id 125csp827805ybg; Tue, 9 Jun 2020 14:01:06 -0700 (PDT) X-Google-Smtp-Source: ABdhPJyj2Fzva3Ac5+jz5ZebGB3hi18Ly4E9rWzv8cMHqfSkAvq02dHbatYn1KTBHFI/Fm/YSAqX X-Received: by 2002:a05:6402:22b3:: with SMTP id cx19mr28079671edb.329.1591736465995; Tue, 09 Jun 2020 14:01:05 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1591736465; cv=none; d=google.com; s=arc-20160816; b=JVhBpreU2ssJMl3VJwvTTPAd3xd/v8Cs+/6LrVKjXEjQReHi5uRqXDlfnnwOd0+1Sy EImRLsNsYhJPdNB0hR6bWrTkwh2Pq30V1hT6F1G442NV4mRFo6ODr7A8fHXWGBmlo/7X Kvad0EDEiDzg+upV24TKLtp/XqE0+y2gxOlbbmPECYQTpjTlRAHNfz32v14UvaWdq3lG uGhbvOlIrOTbUIr7hbPS/qfZ485zlwW6oKfel0/Qbo/HADPMfAKV3XBDltPEIBHMjfAq p+iZYYzjNUqie7EF8yxoG+5eR4XIypUgwNxO1DbAb8HlRzDDU3DimLpX3u7MesM5FYst W2rw== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:in-reply-to:content-disposition :mime-version:references:mail-followup-to:message-id:subject:cc:to :from:date; bh=vHRvDVg3it7TPhwMjkwMo0Z6t4g++YIlXvVqNh4pXv0=; b=TG6m6OCLzdltKGIhCxT1VGX2qVMoFCWoyVS1mDvI2eiPhv81rG5NHHl7F5ELT6b8QG FToL1F4QwCFPmp8u5K0n4DaAlnYdlJeejzmNCc2HxAgdfN+jEmOBJhgpVkOOHFaC3IDm YOS57WiCe7uzz5sM9jZXKL9EhZhgguuaeCSuPVrUJ5UTRS1AmjGkrfvq0YEnSGo1Upqr nMIuna05FT8Wbb4ePLZVLVOYMcf56ZkxfG0IzM1OZHz++tl4YjoOEtvIlYVISMmD30VW VA4ABRG1SXWkHFZcREty7lZI34/iclqSa5wqdFSgoVcMDuY8ANjQA9Dg3bWhpwPrJbRO NHUA== ARC-Authentication-Results: i=1; mx.google.com; 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=fail (p=NONE sp=NONE dis=NONE) header.from=vmware.com Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id lx13si10917783ejb.196.2020.06.09.14.00.39; Tue, 09 Jun 2020 14:01:05 -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; 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=fail (p=NONE sp=NONE dis=NONE) header.from=vmware.com Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1729852AbgFISjx (ORCPT + 99 others); Tue, 9 Jun 2020 14:39:53 -0400 Received: from ex13-edg-ou-002.vmware.com ([208.91.0.190]:56545 "EHLO EX13-EDG-OU-002.vmware.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1728470AbgFISjw (ORCPT ); Tue, 9 Jun 2020 14:39:52 -0400 Received: from sc9-mailhost2.vmware.com (10.113.161.72) by EX13-EDG-OU-002.vmware.com (10.113.208.156) with Microsoft SMTP Server id 15.0.1156.6; Tue, 9 Jun 2020 11:39:49 -0700 Received: from localhost (unknown [10.166.65.245]) by sc9-mailhost2.vmware.com (Postfix) with ESMTP id BC1DDB2985; Tue, 9 Jun 2020 14:39:51 -0400 (EDT) Date: Tue, 9 Jun 2020 11:39:51 -0700 From: Matt Helsley To: Julien Thierry CC: , Josh Poimboeuf , Peter Zijlstra , Steven Rostedt , Sami Tolvanen , Kamalesh Babulal Subject: Re: [RFC][PATCH v4 02/32] objtool: Make recordmcount into mcount subcmd Message-ID: <20200609183951.GE1284251@rlwimi.vmware.com> Mail-Followup-To: Matt Helsley , Julien Thierry , linux-kernel@vger.kernel.org, Josh Poimboeuf , Peter Zijlstra , Steven Rostedt , Sami Tolvanen , Kamalesh Babulal References: <0d44e0b1b8ebce4af8b90f73e351a003ef016005.1591125127.git.mhelsley@vmware.com> MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Disposition: inline In-Reply-To: Received-SPF: None (EX13-EDG-OU-002.vmware.com: mhelsley@vmware.com does not designate permitted sender hosts) Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, Jun 09, 2020 at 10:00:59AM +0100, Julien Thierry wrote: > Hi Matt, > > On 6/2/20 8:49 PM, Matt Helsley wrote: > > Rather than a standalone executable merge recordmcount as a sub command > > of objtool. This is a small step towards cleaning up recordmcount and > > eventually sharing ELF code with objtool. > > > > For the initial step all that's required is a bit of Makefile changes > > and invoking the former main() function from recordmcount.c because the > > subcommand code uses similar function arguments as main when dispatching. > > > > objtool ignores some object files that tracing does not, specifically > > those with OBJECT_FILES_NON_STANDARD Makefile variables. For this reason > > we keep the recordmcount_dep separate from the objtool_dep. When using > > objtool mcount we can also, like the other objtool invocations, just > > depend on the binary rather than the source the binary is built from. > > > > Subsequent patches will gradually convert recordmcount to use > > more and more of libelf/objtool's ELF accessor code. This will both > > clean up recordmcount to be more easily readable and remove > > recordmcount's crude accessor wrapping code. > > > > Signed-off-by: Matt Helsley > > --- ... > > diff --git a/kernel/trace/Kconfig b/kernel/trace/Kconfig > > index 743647005f64..ae74647b06fa 100644 > > --- a/kernel/trace/Kconfig > > +++ b/kernel/trace/Kconfig > > @@ -59,7 +59,7 @@ config HAVE_NOP_MCOUNT > > config HAVE_C_RECORDMCOUNT > > bool > > help > > - C version of recordmcount available? > > + C version of objtool mcount available? > > The "C version" doesn't make much sense here. "Objtool mcount available?" or > "mcount subcommand of objtool available?" perhaps? Agreed, "C version" is nonsense at this point. Looking at the other HAVE_* help messages in that Kconfig suggests: Arch supports objtool mcount subcommand So I've changed it to that. > > diff --git a/tools/objtool/Makefile b/tools/objtool/Makefile > > index 285474a77fe9..ffef73f7f47e 100644 > > --- a/tools/objtool/Makefile > > +++ b/tools/objtool/Makefile > > @@ -31,12 +31,6 @@ OBJTOOL_IN := $(OBJTOOL)-in.o > > LIBELF_FLAGS := $(shell pkg-config libelf --cflags 2>/dev/null) > > LIBELF_LIBS := $(shell pkg-config libelf --libs 2>/dev/null || echo -lelf) > > -RECORDMCOUNT := $(OUTPUT)recordmcount > > -RECORDMCOUNT_IN := $(RECORDMCOUNT)-in.o > > -ifeq ($(BUILD_C_RECORDMCOUNT),y) > > -all: $(RECORDMCOUNT) > > -endif > > - > > all: $(OBJTOOL) > > INCLUDES := -I$(srctree)/tools/include \ > > @@ -55,13 +49,47 @@ AWK = awk > > SUBCMD_CHECK := n > > SUBCMD_ORC := n > > +SUBCMD_MCOUNT := n > > ifeq ($(SRCARCH),x86) > > SUBCMD_CHECK := y > > SUBCMD_ORC := y > > + SUBCMD_MCOUNT := y > > +endif > > + > > +ifeq ($(SRCARCH),arm) > > + SUBCMD_MCOUNT := y > > +endif > > + > > +ifeq ($(SRCARCH),arm64) > > + SUBCMD_MCOUNT := y > > +endif > > + > > +ifeq ($(SRCARCH),ia64) > > + SUBCMD_MCOUNT := y > > +endif > > + > > +ifeq ($(SRCARCH),mips) > > + SUBCMD_MCOUNT := y > > +endif > > + > > +ifeq ($(SRCARCH),powerpc) > > + SUBCMD_MCOUNT := y > > +endif > > + > > +ifeq ($(SRCARCH),s390) > > + SUBCMD_MCOUNT := y > > +endif > > + > > +ifeq ($(SRCARCH),sh) > > + SUBCMD_MCOUNT := y > > +endif > > + > > +ifeq ($(SRCARCH),sparc) > > + SUBCMD_MCOUNT := y > > Is there some arch for which MCOUNT is not supported? If not you could just > have MCOUNT default to 'y' and avoid adding all those tests (or maybe reduce > the numbers and set to 'n' only for arches not supporting it). Yes, there are some which it does not support. For those architectures we keep recordmcount.pl around. It occured to me that with your suggestion to use more CONFIG_ variables we could eliminate this pattern and replace it with these pseudo-patches: +++ b/kernel/trace/Kconfig +config OBJTOOL_SUBCMD_MCOUNT + bool + depends on HAVE_C_RECORDMCOUNT + select OBJTOOL_SUBCMDS + help + Record mcount call locations using objtool and then change the Makefiles to use the CONFIG_ variables rather than have one ifeq block per arch: +++ b/tools/objtool/Makefile +SUBCMD_MCOUNT := $(CONFIG_OBJTOOL_SUBCMD_MCOUNT) Does this seem like a good use of CONFIG_ variables or is it going too far? I haven't changed to this pattern just yet -- I'm hoping you and Josh or Peter might weigh in with your preferences. > > > endif > > -export SUBCMD_CHECK SUBCMD_ORC > > +export SUBCMD_CHECK SUBCMD_ORC SUBCMD_MCOUNT ... > > diff --git a/tools/objtool/builtin.h b/tools/objtool/builtin.h > > index 85c979caa367..9c7331592fa7 100644 > > --- a/tools/objtool/builtin.h > > +++ b/tools/objtool/builtin.h > > @@ -12,5 +12,7 @@ extern bool no_fp, no_unreachable, retpoline, module, backtrace, uaccess, stats, > > extern int cmd_check(int argc, const char **argv); > > extern int cmd_orc(int argc, const char **argv); > > +extern bool is_cmd_mcount_available(void); > > This appears to be unused. Indeed, removed. Thanks! Cheers, -Matt Helsley