From nobody Thu Jun 25 00:33:29 2026 Received: from akranes.kaiser.cx (akranes.kaiser.cx [152.53.16.207]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id E18993AA4F8 for ; Mon, 8 Jun 2026 20:19:35 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=152.53.16.207 ARC-Seal: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780949978; cv=none; b=GvhF+GvhYxRRgPciXQdMlZi/aXpSKaGvnAu/2a3DzEqqAnKwxYYCemYeGmLnQ46fHo4qhMzSxhsILk6aLi5ACvveqv2WCw0LBouMsLEpNbpzAs4D9I45LtZWsjtmqqXcNAyPdzH5JQjzzjJQitGIHL/BPU26GDP9DKeCYRuueX0= ARC-Message-Signature: i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1780949978; c=relaxed/simple; bh=yRa9kMH/sFHsgDsdjmKc5uyYpyPrAgJvGcy/yV0Z7Fc=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version; b=u8G7vUh4siAvn3rikryP5DZFtKDjPXfvE7JkhdVOcA1CKmJ3Yp9hP3wbddo45sjwnMUyXeOfwVkLkVYx6aNf+D7GxzKnKpXbdlyPvMCMgPQze3BjNoA6Xop9bmfFoJxV4HnBn7TS3oDCE20mvYNtJ8E9/yaglhhtiNC/J4B4WL4= ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=kaiser.cx; spf=pass smtp.mailfrom=kaiser.cx; arc=none smtp.client-ip=152.53.16.207 Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=kaiser.cx Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=kaiser.cx Received: from ipservice-092-209-184-216.092.209.pools.vodafone-ip.de ([92.209.184.216] helo=nb282.user.codasip.com) by akranes.kaiser.cx with esmtpsa (TLS1.3) tls TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (Exim 4.98.2) (envelope-from ) id 1wWgRT-00000001vbF-2T2A; Mon, 08 Jun 2026 22:19:27 +0200 From: Martin Kaiser To: Steven Rostedt , Masami Hiramatsu , Paul Walmsley , Palmer Dabbelt , Chen Pei Cc: linux-riscv@lists.infradead.org, linux-kernel@vger.kernel.org, Martin Kaiser Subject: [PATCH] riscv: ftrace: sorttable: fix mcount sorting Date: Mon, 8 Jun 2026 22:18:27 +0200 Message-ID: <20260608201904.715374-1-martin@kaiser.cx> X-Mailer: git-send-email 2.43.7 Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Commit de04fca5d2f8 ("riscv: ftrace: select HAVE_BUILDTIME_MCOUNT_SORT") enabled mcount sorting for risc-v. On my system, the sorting changes all entries to address 0. The startup test reports that the mcount section is properly sorted, but no traceable functions are registered at boot time. [ 0.000000] ftrace section at ffffffff8101bba0 sorted properly [ 0.000000] ftrace: allocating 0 entries in 128 pages [ 0.000000] ftrace: allocated 128 pages with 1 groups The sorttable helper program does not take into account that the -fpatchable-function-entry compiler flag reserves an additional 8 bytes before each traceable function. (The size in bytes is the same for RV32/64 or compressed/uncompressed instructions). Define before_func =3D 8 to fix the mcount sorting for risc-v, share this setting with arm64. Fixes: de04fca5d2f8 ("riscv: ftrace: select HAVE_BUILDTIME_MCOUNT_SORT") Signed-off-by: Martin Kaiser --- scripts/sorttable.c | 10 ++++++++-- 1 file changed, 8 insertions(+), 2 deletions(-) diff --git a/scripts/sorttable.c b/scripts/sorttable.c index e8ed11c680c6..da70f0938d04 100644 --- a/scripts/sorttable.c +++ b/scripts/sorttable.c @@ -895,13 +895,19 @@ static int do_file(char const *const fname, void *add= r) #ifdef MCOUNT_SORT_ENABLED sort_reloc =3D true; rela_type =3D 0x403; - /* arm64 uses patchable function entry placing before function */ +#endif + /* fallthrough */ + case EM_RISCV: +#ifdef MCOUNT_SORT_ENABLED + /* + * risc-v and arm64 use patchable function entry that stores + * 8 bytes of nops before the function + */ before_func =3D 8; #endif /* fallthrough */ case EM_386: case EM_LOONGARCH: - case EM_RISCV: case EM_S390: case EM_X86_64: custom_sort =3D sort_relative_table_with_data; --=20 2.43.7