Received: by 2002:a25:683:0:0:0:0:0 with SMTP id 125csp813169ybg; Tue, 9 Jun 2020 13:34:46 -0700 (PDT) X-Google-Smtp-Source: ABdhPJwctkUPsGu69KJUlvrQwUjzYMo4RQBtQztVDdfjGAcWqTxq/Q4r8uFjsC69pSwMlgY5hyCM X-Received: by 2002:a17:906:e257:: with SMTP id gq23mr171841ejb.398.1591734885909; Tue, 09 Jun 2020 13:34:45 -0700 (PDT) ARC-Seal: i=1; a=rsa-sha256; t=1591734885; cv=none; d=google.com; s=arc-20160816; b=givHelqfdLmB4NN4m7mmnU3XKgUgkeymdk9scQ5uzQXhu+whUieJ98x5wQqE5uvPzw gXb/Q3wH+IUyYPNIUw38W3XW1YvEnm+xIBPNDoQYZymlyncByAh9eQDyIS0tApunQmFf aRTwt2DO6MSwMD7ipOiu59Tdzi4q4Aa4L3fyJsj511dVpFumhsbyz1bS0Kizl7xc9LPM Kw5yxJCKxB8v9bfk99ZQBPy2RCzlHRipdhUFgAXfXfeWpQsVn8zelD2LIoz5jY1Hx5yO 5WuPw2raMd4f4M8lHBPQNbRvtsBxtpFvbz2ioRSvUImleQ9md7M90ZZZAYam8j14qp7q E6QA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=arc-20160816; h=list-id:precedence:sender:content-transfer-encoding:mime-version :references:in-reply-to:message-id:subject:cc:to:from:date; bh=163Iz+4TWpRHQlYsKWM+Gp+ASVcF+VqjH5hqq1k8j+4=; b=YcVAwM1XDaww7KG04ZLwUFWlfgjwmO/Mc+k1xYurnqafKJUqCuDL1+276S8gj/j7UR ZnRdy4n3TA0L6urfMiAa9Azd7Wd6jAkShtqUTtO2b40TWi5x1sSLTtkUSFn9F6h4jgwN apY6UrNqxl5Dp87gwoOFCcWcThFleNhDh73/vmmVPyrDa8ibNl3Rm6pHQ8HzYH7D7mnM bxoRBtrOEboWKEeoU4Cz8uAemZLke6IbgtYjpQdo1zuwjYW19LMa2iI5Nm6frHW/N32T /YUSQeGNlkYFW9u2L6MI8Acu84zTPEJiBDRJ4AVH4I7u+FTvWR1bJyJnIxf1SZOu+MhM DChg== 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 Return-Path: Received: from vger.kernel.org (vger.kernel.org. [23.128.96.18]) by mx.google.com with ESMTP id k11si11531738eji.338.2020.06.09.13.34.23; Tue, 09 Jun 2020 13:34:45 -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 Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1731945AbgFISwL (ORCPT + 99 others); Tue, 9 Jun 2020 14:52:11 -0400 Received: from mail.kernel.org ([198.145.29.99]:36194 "EHLO mail.kernel.org" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1729371AbgFISwL (ORCPT ); Tue, 9 Jun 2020 14:52:11 -0400 Received: from oasis.local.home (cpe-66-24-58-225.stny.res.rr.com [66.24.58.225]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mail.kernel.org (Postfix) with ESMTPSA id E3D6C2068D; Tue, 9 Jun 2020 18:52:08 +0000 (UTC) Date: Tue, 9 Jun 2020 14:52:07 -0400 From: Steven Rostedt To: Matt Helsley Cc: Julien Thierry , , Josh Poimboeuf , Peter Zijlstra , Sami Tolvanen , Kamalesh Babulal Subject: Re: [RFC][PATCH v4 02/32] objtool: Make recordmcount into mcount subcmd Message-ID: <20200609145207.1d9dafa2@oasis.local.home> In-Reply-To: <20200609183951.GE1284251@rlwimi.vmware.com> References: <0d44e0b1b8ebce4af8b90f73e351a003ef016005.1591125127.git.mhelsley@vmware.com> <20200609183951.GE1284251@rlwimi.vmware.com> X-Mailer: Claws Mail 3.17.3 (GTK+ 2.24.32; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Sender: linux-kernel-owner@vger.kernel.org Precedence: bulk List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Tue, 9 Jun 2020 11:39:51 -0700 Matt Helsley wrote: > > > +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) If you can make this work, this is definitely the way to go. -- Steve > > 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.