From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org Received: from lists.ozlabs.org (lists.ozlabs.org [112.213.38.117]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.lore.kernel.org (Postfix) with ESMTPS id 22435C433FE for ; Wed, 27 Apr 2022 13:54:46 +0000 (UTC) Received: from boromir.ozlabs.org (localhost [IPv6:::1]) by lists.ozlabs.org (Postfix) with ESMTP id 4KpKxc5BK6z3brx for ; Wed, 27 Apr 2022 23:54:44 +1000 (AEST) Authentication-Results: lists.ozlabs.org; spf=pass (sender SPF authorized) smtp.mailfrom=kernel.org (client-ip=2604:1380:4641:c500::1; helo=dfw.source.kernel.org; envelope-from=srs0=av7o=vf=goodmis.org=rostedt@kernel.org; receiver=) Received: from dfw.source.kernel.org (dfw.source.kernel.org [IPv6:2604:1380:4641:c500::1]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by lists.ozlabs.org (Postfix) with ESMTPS id 4KpKx92JbMz2ync for ; Wed, 27 Apr 2022 23:54:21 +1000 (AEST) Received: from smtp.kernel.org (relay.kernel.org [52.25.139.140]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by dfw.source.kernel.org (Postfix) with ESMTPS id 6841461D51; Wed, 27 Apr 2022 13:54:18 +0000 (UTC) Received: by smtp.kernel.org (Postfix) with ESMTPSA id 0A50CC385A9; Wed, 27 Apr 2022 13:54:16 +0000 (UTC) Date: Wed, 27 Apr 2022 09:54:15 -0400 From: Steven Rostedt To: "Naveen N. Rao" Subject: Re: [PATCH 2/2] recordmcount: Handle sections with no non-weak symbols Message-ID: <20220427095415.594e5120@gandalf.local.home> In-Reply-To: <1b9566f0e7185fb8fd8ef2535add7a081501ccc8.1651047542.git.naveen.n.rao@linux.vnet.ibm.com> References: <1b9566f0e7185fb8fd8ef2535add7a081501ccc8.1651047542.git.naveen.n.rao@linux.vnet.ibm.com> X-Mailer: Claws Mail 3.17.8 (GTK+ 2.24.33; x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-BeenThere: linuxppc-dev@lists.ozlabs.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Linux on PowerPC Developers Mail List List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: llvm@lists.linux.dev, Nick Desaulniers , linux-kernel@vger.kernel.org, Nathan Chancellor , linuxppc-dev@lists.ozlabs.org Errors-To: linuxppc-dev-bounces+linuxppc-dev=archiver.kernel.org@lists.ozlabs.org Sender: "Linuxppc-dev" On Wed, 27 Apr 2022 15:01:22 +0530 "Naveen N. Rao" wrote: > If one or both of these weak functions are overridden in future, in the > final vmlinux mcount table, references to these will change over to the > non-weak variant which has its own mcount location entry. As such, there > will now be two entries for these functions, both pointing to the same > non-weak location. But is that really true in all cases? x86 uses fentry these days, and other archs do things differently too. But the original mcount (-pg) call happened *after* the frame setup. That means the offset of the mcount call would be at different offsets wrt the start of the function. If you have one of these architectures that still use mcount, and the weak function doesn't have the same size frame setup as the overriding function, then the addresses will not be the same. -- Steve > We don't need the non-weak locations since they will > never be executed. Ftrace skips the duplicate entries due to a previous > commit.