[RFC PATCH v2 0/4] Test annotate with data type profiling

[RFC PATCH v2 0/4] Test annotate with data type profiling

[Dmitrii Dolgov]

Add shell tests for data type profiling, including C and rust.

To support the rust test, a new workload with rust code was introduced.
To build it only when rust is actually available, also add a feature
test for rust compiler and guard everything behind it.

Changes in v2:
- Switched to use mem record.
- Fixed the build issue with a custom output.
- Separated patches for the workload and tests.
- Added new test for C code.
- Added a feature test for rust compiler.

Dmitrii Dolgov (4):
  tools/build: Add a feature test for rust compiler
  perf test workload: Add code_with_type test workload
  perf tests: Test annotate with data type profiling and rust
  perf tests: Test annotate with data type profiling and C

 tools/build/Makefile.build                    | 14 ++++
 tools/build/Makefile.feature                  |  6 +-
 tools/build/feature/Makefile                  |  7 ++
 tools/build/feature/test-rust.rs              |  4 +
 tools/perf/Makefile.config                    | 11 +++
 tools/perf/Makefile.perf                      |  2 +-
 tools/perf/builtin-check.c                    |  1 +
 tools/perf/tests/builtin-test.c               |  4 +
 tools/perf/tests/shell/data_type_profiling.sh | 84 +++++++++++++++++++
 tools/perf/tests/tests.h                      |  4 +
 tools/perf/tests/workloads/Build              |  5 ++
 tools/perf/tests/workloads/code_with_type.c   | 46 ++++++++++
 tools/perf/tests/workloads/code_with_type.rs  | 23 +++++
 tools/scripts/Makefile.include                |  2 +
 14 files changed, 210 insertions(+), 3 deletions(-)
 create mode 100644 tools/build/feature/test-rust.rs
 create mode 100755 tools/perf/tests/shell/data_type_profiling.sh
 create mode 100644 tools/perf/tests/workloads/code_with_type.c
 create mode 100644 tools/perf/tests/workloads/code_with_type.rs


base-commit: 36a1b0061a584430277861fe5d8bd107aef26137
-- 
2.52.0

[RFC PATCH v2 1/4] tools/build: Add a feature test for rust compiler

[Dmitrii Dolgov]

Add a feature test to identify if the rust compiler is available, so
that perf could build rust based worloads based on that.

Signed-off-by: Dmitrii Dolgov <9erthalion6@gmail.com>
---
 tools/build/Makefile.feature     |  6 ++++--
 tools/build/feature/Makefile     |  7 +++++++
 tools/build/feature/test-rust.rs |  4 ++++
 tools/perf/Makefile.config       | 11 +++++++++++
 tools/perf/builtin-check.c       |  1 +
 5 files changed, 27 insertions(+), 2 deletions(-)
 create mode 100644 tools/build/feature/test-rust.rs

diff --git a/tools/build/Makefile.feature b/tools/build/Makefile.feature
index 7f119eafc7c..64d21152fc8 100644
--- a/tools/build/Makefile.feature
+++ b/tools/build/Makefile.feature
@@ -100,7 +100,8 @@ FEATURE_TESTS_BASIC :=                  \
         disassembler-four-args		\
         disassembler-init-styled	\
         file-handle			\
-        libopenssl
+        libopenssl			\
+        rust
 
 # FEATURE_TESTS_BASIC + FEATURE_TESTS_EXTRA is the complete list
 # of all feature tests
@@ -149,7 +150,8 @@ FEATURE_DISPLAY ?=              \
          bpf			\
          libaio			\
          libzstd		\
-         libopenssl
+         libopenssl		\
+         rust
 
 #
 # Declare group members of a feature to display the logical OR of the detection
diff --git a/tools/build/feature/Makefile b/tools/build/feature/Makefile
index 5c15572d505..9ae69d85716 100644
--- a/tools/build/feature/Makefile
+++ b/tools/build/feature/Makefile
@@ -112,6 +112,9 @@ __BUILD = $(CC) $(CFLAGS) -MD -Wall -Werror -o $@ $(patsubst %.bin,%.c,$(@F)) $(
 __BUILDXX = $(CXX) $(CXXFLAGS) -MD -Wall -Werror -o $@ $(patsubst %.bin,%.cpp,$(@F)) $(LDFLAGS)
   BUILDXX = $(__BUILDXX) > $(@:.bin=.make.output) 2>&1
 
+__BUILDRS = $(RUSTC) $(RUSTC_FLAGS) -o $@ $(patsubst %.bin,%.rs,$(@F))
+  BUILDRS = $(__BUILDRS) > $(@:.bin=.make.output) 2>&1
+
 ###############################
 
 $(OUTPUT)test-all.bin:
@@ -388,6 +391,10 @@ $(OUTPUT)test-libopenssl.bin:
 $(OUTPUT)test-bpftool-skeletons.bin:
 	$(SYSTEM_BPFTOOL) version | grep '^features:.*skeletons' \
 		> $(@:.bin=.make.output) 2>&1
+
+$(OUTPUT)test-rust.bin:
+	$(BUILDRS) > $(@:.bin=.make.output) 2>&1
+
 ###############################
 
 clean:
diff --git a/tools/build/feature/test-rust.rs b/tools/build/feature/test-rust.rs
new file mode 100644
index 00000000000..f2fc91cc4f6
--- /dev/null
+++ b/tools/build/feature/test-rust.rs
@@ -0,0 +1,4 @@
+// SPDX-License-Identifier: GPL-2.0
+fn main() {
+    println!("hi")
+}
diff --git a/tools/perf/Makefile.config b/tools/perf/Makefile.config
index b683aab3ab9..94aecfe38b9 100644
--- a/tools/perf/Makefile.config
+++ b/tools/perf/Makefile.config
@@ -1153,6 +1153,17 @@ ifneq ($(NO_LIBTRACEEVENT),1)
   endif
 endif
 
+ifndef NO_RUST
+  ifneq ($(feature-rust), 1)
+    $(warning Rust is not found. Test workloads with rust are disabled.)
+    NO_RUST := 1
+  else
+    NO_RUST := 0
+    CFLAGS += -DHAVE_RUST_SUPPORT
+    $(call detected,CONFIG_RUST_SUPPORT)
+  endif
+endif
+
 # Among the variables below, these:
 #   perfexecdir
 #   libbpf_include_dir
diff --git a/tools/perf/builtin-check.c b/tools/perf/builtin-check.c
index d19769a8f68..27a41beeadd 100644
--- a/tools/perf/builtin-check.c
+++ b/tools/perf/builtin-check.c
@@ -60,6 +60,7 @@ struct feature_status supported_features[] = {
 	FEATURE_STATUS("numa_num_possible_cpus", HAVE_LIBNUMA_SUPPORT),
 	FEATURE_STATUS("zlib", HAVE_ZLIB_SUPPORT),
 	FEATURE_STATUS("zstd", HAVE_ZSTD_SUPPORT),
+	FEATURE_STATUS("rust", HAVE_RUST_SUPPORT),
 
 	/* this should remain at end, to know the array end */
 	FEATURE_STATUS(NULL, _)
-- 
2.52.0

[RFC PATCH v2 2/4] perf test workload: Add code_with_type test workload

[Dmitrii Dolgov]

The purpose of the workload is to gather samples of rust runtime. To
achiever that it has a dummy rust library linked with it. Per
recommendations for such scenarios [1], the rust library is statically
linked.

An example:

$ perf record perf test -w code_with_type
[ perf record: Woken up 1 times to write data ]
[ perf record: Captured and wrote 0.160 MB perf.data (4074 samples) ]

$ perf report --stdio --dso perf -s srcfile,srcline
    45.16%  ub_checks.rs       ub_checks.rs:72
     6.72%  code_with_type.rs  code_with_type.rs:15
     6.64%  range.rs           range.rs:767
     4.26%  code_with_type.rs  code_with_type.rs:21
     4.23%  range.rs           range.rs:0
     3.99%  code_with_type.rs  code_with_type.rs:16
    [...]

[1]: https://doc.rust-lang.org/reference/linkage.html#mixed-rust-and-foreign-codebases

Signed-off-by: Dmitrii Dolgov <9erthalion6@gmail.com>
---
 tools/build/Makefile.build                   | 14 ++++++
 tools/perf/Makefile.perf                     |  2 +-
 tools/perf/tests/builtin-test.c              |  4 ++
 tools/perf/tests/tests.h                     |  4 ++
 tools/perf/tests/workloads/Build             |  5 +++
 tools/perf/tests/workloads/code_with_type.c  | 46 ++++++++++++++++++++
 tools/perf/tests/workloads/code_with_type.rs | 23 ++++++++++
 tools/scripts/Makefile.include               |  2 +
 8 files changed, 99 insertions(+), 1 deletion(-)
 create mode 100644 tools/perf/tests/workloads/code_with_type.c
 create mode 100644 tools/perf/tests/workloads/code_with_type.rs

diff --git a/tools/build/Makefile.build b/tools/build/Makefile.build
index 3584ff30860..60e65870eae 100644
--- a/tools/build/Makefile.build
+++ b/tools/build/Makefile.build
@@ -76,6 +76,14 @@ quiet_cmd_host_ld_multi = HOSTLD  $@
       cmd_host_ld_multi = $(if $(strip $(obj-y)),\
                           $(HOSTLD) -r -o $@  $(filter $(obj-y),$^),rm -f $@; $(HOSTAR) rcs $@)
 
+rust_common_cmd = \
+	$(RUSTC) $(rust_flags) \
+	--crate-type staticlib -L $(objtree)/rust/ \
+	--emit=dep-info=$(depfile),link
+
+quiet_cmd_rustc_a_rs = $(RUSTC) $(quiet_modtag) $@
+      cmd_rustc_a_rs = $(rust_common_cmd) -o $@ -g $< $(cmd_objtool)
+
 ifneq ($(filter $(obj),$(hostprogs)),)
   host = host_
 endif
@@ -105,6 +113,12 @@ $(OUTPUT)%.s: %.c FORCE
 	$(call rule_mkdir)
 	$(call if_changed_dep,cc_s_c)
 
+# it's recommended to build a static rust library, when a foreight (to rust)
+# linker is used.
+$(OUTPUT)%.a: %.rs FORCE
+	$(call rule_mkdir)
+	$(call if_changed_dep,rustc_a_rs)
+
 # bison and flex files are generated in the OUTPUT directory
 # so it needs a separate rule to depend on them properly
 $(OUTPUT)%-bison.o: $(OUTPUT)%-bison.c FORCE
diff --git a/tools/perf/Makefile.perf b/tools/perf/Makefile.perf
index 2a7e5814b15..a6d8ca3e923 100644
--- a/tools/perf/Makefile.perf
+++ b/tools/perf/Makefile.perf
@@ -271,7 +271,7 @@ ifeq ($(PYLINT),1)
   PYLINT := $(shell which pylint 2> /dev/null)
 endif
 
-export srctree OUTPUT RM CC CXX LD AR CFLAGS CXXFLAGS V BISON FLEX AWK
+export srctree OUTPUT RM CC CXX RUSTC LD AR CFLAGS CXXFLAGS V BISON FLEX AWK
 export HOSTCC HOSTLD HOSTAR HOSTCFLAGS SHELLCHECK MYPY PYLINT
 
 include $(srctree)/tools/build/Makefile.include
diff --git a/tools/perf/tests/builtin-test.c b/tools/perf/tests/builtin-test.c
index e2490652f03..06507066213 100644
--- a/tools/perf/tests/builtin-test.c
+++ b/tools/perf/tests/builtin-test.c
@@ -154,6 +154,10 @@ static struct test_workload *workloads[] = {
 	&workload__landlock,
 	&workload__traploop,
 	&workload__inlineloop,
+
+#ifdef HAVE_RUST_SUPPORT
+	&workload__code_with_type,
+#endif
 };
 
 #define workloads__for_each(workload) \
diff --git a/tools/perf/tests/tests.h b/tools/perf/tests/tests.h
index 1f0f8b267fb..f5f1238d1f7 100644
--- a/tools/perf/tests/tests.h
+++ b/tools/perf/tests/tests.h
@@ -242,6 +242,10 @@ DECLARE_WORKLOAD(landlock);
 DECLARE_WORKLOAD(traploop);
 DECLARE_WORKLOAD(inlineloop);
 
+#ifdef HAVE_RUST_SUPPORT
+DECLARE_WORKLOAD(code_with_type);
+#endif
+
 extern const char *dso_to_test;
 extern const char *test_objdump_path;
 
diff --git a/tools/perf/tests/workloads/Build b/tools/perf/tests/workloads/Build
index 866a00bd14a..2ef97f7affc 100644
--- a/tools/perf/tests/workloads/Build
+++ b/tools/perf/tests/workloads/Build
@@ -10,6 +10,11 @@ perf-test-y += landlock.o
 perf-test-y += traploop.o
 perf-test-y += inlineloop.o
 
+ifeq ($(CONFIG_RUST_SUPPORT),y)
+    perf-test-y += code_with_type.o
+    perf-test-y += code_with_type.a
+endif
+
 CFLAGS_sqrtloop.o         = -g -O0 -fno-inline -U_FORTIFY_SOURCE
 CFLAGS_leafloop.o         = -g -O0 -fno-inline -fno-omit-frame-pointer -U_FORTIFY_SOURCE
 CFLAGS_brstack.o          = -g -O0 -fno-inline -U_FORTIFY_SOURCE
diff --git a/tools/perf/tests/workloads/code_with_type.c b/tools/perf/tests/workloads/code_with_type.c
new file mode 100644
index 00000000000..65d7be7dac2
--- /dev/null
+++ b/tools/perf/tests/workloads/code_with_type.c
@@ -0,0 +1,46 @@
+// SPDX-License-Identifier: GPL-2.0
+#include <pthread.h>
+#include <stdlib.h>
+#include <signal.h>
+#include <unistd.h>
+#include <linux/compiler.h>
+#include "../tests.h"
+
+extern void test_rs(uint count);
+
+static volatile sig_atomic_t done;
+
+static void sighandler(int sig __maybe_unused)
+{
+	done = 1;
+}
+
+static int code_with_type(int argc, const char **argv)
+{
+	int sec = 1, num_loops = 100;
+
+	pthread_setname_np(pthread_self(), "perf-code-with-type");
+	if (argc > 0)
+		sec = atoi(argv[0]);
+
+	if (argc > 1)
+		num_loops = atoi(argv[1]);
+
+	signal(SIGINT, sighandler);
+	signal(SIGALRM, sighandler);
+	alarm(sec);
+
+	/*
+	 * Rust doesn't have signal management in the standard library. To
+	 * not deal with any external crates, offload signal handling to the
+	 * outside code.
+	 */
+	while (!done) {
+		test_rs(num_loops);
+		continue;
+	}
+
+	return 0;
+}
+
+DEFINE_WORKLOAD(code_with_type);
diff --git a/tools/perf/tests/workloads/code_with_type.rs b/tools/perf/tests/workloads/code_with_type.rs
new file mode 100644
index 00000000000..3b91e51919d
--- /dev/null
+++ b/tools/perf/tests/workloads/code_with_type.rs
@@ -0,0 +1,23 @@
+// SPDX-License-Identifier: GPL-2.0
+
+// We're going to look for this structure in the data type profiling report
+#[allow(dead_code)]
+struct Buf {
+    data1: u64,
+    data2: String,
+    data3: u64,
+}
+
+#[no_mangle]
+pub extern "C" fn test_rs(count: u32) {
+    let mut b =  Buf { data1: 0, data2: String::from("data"), data3: 0};
+
+    for _ in 1..count {
+        b.data1 += 1;
+        if b.data1 == 123 {
+            b.data1 += 1;
+        }
+
+        b.data3 += b.data1;
+    }
+}
diff --git a/tools/scripts/Makefile.include b/tools/scripts/Makefile.include
index ded48263dd5..b5ecf137feb 100644
--- a/tools/scripts/Makefile.include
+++ b/tools/scripts/Makefile.include
@@ -94,6 +94,8 @@ LLVM_STRIP	?= llvm-strip
 # Some tools require bpftool
 SYSTEM_BPFTOOL	?= bpftool
 
+RUSTC		?= rustc
+
 ifeq ($(CC_NO_CLANG), 1)
 EXTRA_WARNINGS += -Wstrict-aliasing=3
 
-- 
2.52.0

[RFC PATCH v2 3/4] perf tests: Test annotate with data type profiling and rust

[Dmitrii Dolgov]

Exercise the annotate command with data type profiling feature on the
rust runtime. For that add a new shell test, which will profile the
code_with_type workload, then annotate the result expecting to see some
data structures from the rust code.

Signed-off-by: Dmitrii Dolgov <9erthalion6@gmail.com>
---
 tools/perf/tests/shell/data_type_profiling.sh | 69 +++++++++++++++++++
 1 file changed, 69 insertions(+)
 create mode 100755 tools/perf/tests/shell/data_type_profiling.sh

diff --git a/tools/perf/tests/shell/data_type_profiling.sh b/tools/perf/tests/shell/data_type_profiling.sh
new file mode 100755
index 00000000000..cdc9adb7d70
--- /dev/null
+++ b/tools/perf/tests/shell/data_type_profiling.sh
@@ -0,0 +1,69 @@
+#!/bin/bash
+# perf data type profiling tests
+# SPDX-License-Identifier: GPL-2.0
+
+set -e
+
+# The logic below follows the same line as the annotate test, but looks for a
+# data type profiling manifestation
+testtype="# data-type: struct Buf"
+
+err=0
+perfdata=$(mktemp /tmp/__perf_test.perf.data.XXXXX)
+perfout=$(mktemp /tmp/__perf_test.perf.out.XXXXX)
+testprog="perf test -w code_with_type"
+
+cleanup() {
+  rm -rf "${perfdata}" "${perfout}"
+  rm -rf "${perfdata}".old
+
+  trap - EXIT TERM INT
+}
+
+trap_cleanup() {
+  echo "Unexpected signal in ${FUNCNAME[1]}"
+  cleanup
+  exit 1
+}
+trap trap_cleanup EXIT TERM INT
+
+test_basic_annotate() {
+  mode=$1
+  echo "${mode} perf annotate test"
+  if [ "x${mode}" == "xBasic" ]
+  then
+    perf mem record -o "${perfdata}" ${testprog} 2> /dev/null
+  else
+    perf mem record -o - ${testprog} 2> /dev/null > "${perfdata}"
+  fi
+  if [ "x$?" != "x0" ]
+  then
+    echo "${mode} annotate [Failed: perf record]"
+    err=1
+    return
+  fi
+
+  # Generate the annotated output file
+  if [ "x${mode}" == "xBasic" ]
+  then
+    perf annotate --code-with-type -i "${perfdata}" --stdio --percent-limit 1 2> /dev/null > "${perfout}"
+  else
+    perf annotate --code-with-type -i - --stdio 2> /dev/null --percent-limit 1 < "${perfdata}" > "${perfout}"
+  fi
+
+  # check if it has the target data type
+  if ! grep -q "${testtype}" "${perfout}"
+  then
+    echo "${mode} annotate [Failed: missing target data type]"
+    cat "${perfout}"
+    err=1
+    return
+  fi
+  echo "${mode} annotate test [Success]"
+}
+
+test_basic_annotate Basic
+test_basic_annotate Pipe
+
+cleanup
+exit $err
-- 
2.52.0

[RFC PATCH v2 4/4] perf tests: Test annotate with data type profiling and C

[Dmitrii Dolgov]

Exercise the annotate command with data type profiling feature with C. For that
extend the existing data type profiling shell test to profile the datasym
workload, then annotate the result expecting to see some data structures from
the C code.

Signed-off-by: Dmitrii Dolgov <9erthalion6@gmail.com>
---
 tools/perf/tests/shell/data_type_profiling.sh | 31 ++++++++++++++-----
 1 file changed, 23 insertions(+), 8 deletions(-)

diff --git a/tools/perf/tests/shell/data_type_profiling.sh b/tools/perf/tests/shell/data_type_profiling.sh
index cdc9adb7d70..a230f5d4c42 100755
--- a/tools/perf/tests/shell/data_type_profiling.sh
+++ b/tools/perf/tests/shell/data_type_profiling.sh
@@ -6,12 +6,14 @@ set -e
 
 # The logic below follows the same line as the annotate test, but looks for a
 # data type profiling manifestation
-testtype="# data-type: struct Buf"
+
+# Values in testtypes and testprogs should match
+testtypes=("# data-type: struct Buf" "# data-type: struct _buf")
+testprogs=("perf test -w code_with_type" "perf test -w datasym")
 
 err=0
 perfdata=$(mktemp /tmp/__perf_test.perf.data.XXXXX)
 perfout=$(mktemp /tmp/__perf_test.perf.out.XXXXX)
-testprog="perf test -w code_with_type"
 
 cleanup() {
   rm -rf "${perfdata}" "${perfout}"
@@ -29,12 +31,23 @@ trap trap_cleanup EXIT TERM INT
 
 test_basic_annotate() {
   mode=$1
-  echo "${mode} perf annotate test"
+  runtime=$2
+
+  echo "${mode} ${runtime} perf annotate test"
+
+  case "x${runtime}" in
+    "xRust")
+    index=0 ;;
+
+    "xC")
+    index=1 ;;
+  esac
+
   if [ "x${mode}" == "xBasic" ]
   then
-    perf mem record -o "${perfdata}" ${testprog} 2> /dev/null
+    perf mem record -o "${perfdata}" ${testprogs[$index]} 2> /dev/null
   else
-    perf mem record -o - ${testprog} 2> /dev/null > "${perfdata}"
+    perf mem record -o - ${testprogs[$index]} 2> /dev/null > "${perfdata}"
   fi
   if [ "x$?" != "x0" ]
   then
@@ -52,7 +65,7 @@ test_basic_annotate() {
   fi
 
   # check if it has the target data type
-  if ! grep -q "${testtype}" "${perfout}"
+  if ! grep -q "${testtypes[$index]}" "${perfout}"
   then
     echo "${mode} annotate [Failed: missing target data type]"
     cat "${perfout}"
@@ -62,8 +75,10 @@ test_basic_annotate() {
   echo "${mode} annotate test [Success]"
 }
 
-test_basic_annotate Basic
-test_basic_annotate Pipe
+test_basic_annotate Basic Rust
+test_basic_annotate Pipe Rust
+test_basic_annotate Basic C
+test_basic_annotate Pipe C
 
 cleanup
 exit $err
-- 
2.52.0

Re: [RFC PATCH v2 0/4] Test annotate with data type profiling

[Arnaldo Carvalho de Melo]

On Sun, Feb 08, 2026 at 01:22:22PM +0100, Dmitrii Dolgov wrote:
> Add shell tests for data type profiling, including C and rust.
> 
> To support the rust test, a new workload with rust code was introduced.
> To build it only when rust is actually available, also add a feature
> test for rust compiler and guard everything behind it.
> 
> Changes in v2:
> - Switched to use mem record.
> - Fixed the build issue with a custom output.
> - Separated patches for the workload and tests.
> - Added new test for C code.
> - Added a feature test for rust compiler.

Thanks, tested it, everything working as advertised:

⬢ [acme@toolbx perf-tools-next]$ m
make: Entering directory '/home/acme/git/linux/tools/perf'
  BUILD:   Doing 'make -j32' parallel build
Warning: Kernel ABI header differences:
  diff -u tools/arch/arm64/include/asm/cputype.h arch/arm64/include/asm/cputype.h
  diff -u tools/perf/arch/s390/entry/syscalls/syscall.tbl arch/s390/kernel/syscalls/syscall.tbl

Auto-detecting system features:
...                  libdw: [ on  ]
...                  glibc: [ on  ]
...                 libelf: [ on  ]
...                libnuma: [ on  ]
... numa_num_possible_cpus: [ on  ]
...              libpython: [ on  ]
...            libcapstone: [ on  ]
...              llvm-perf: [ on  ]
...                   zlib: [ on  ]
...                   lzma: [ on  ]
...                    bpf: [ on  ]
...                 libaio: [ on  ]
...                libzstd: [ on  ]
...             libopenssl: [ on  ]
...                   rust: [ on  ] <-------------------------

  INSTALL libsubcmd_headers
<SNIP>

⬢ [acme@toolbx perf-tools-next]$ perf record perf test -w code_with_type
[ perf record: Woken up 2 times to write data ]
[ perf record: Captured and wrote 0.162 MB perf.data (4036 samples) ]
⬢ [acme@toolbx perf-tools-next]$ perf report --stdio --dso perf -s srcfile,srcline | head -20
# To display the perf.data header info, please use --header/--header-only options.
#
#
# Total Lost Samples: 0
#
# Samples: 4K of event 'cpu/cycles/Pu'
# Event count (approx.): 5337677712
#
# Overhead  Source File        Source:Line
# ........  .................  ..............................................................
#
    25.53%  cmp.rs             cmp.rs:1903
    16.66%  code_with_type.rs  code_with_type.rs:15
    14.48%  ub_checks.rs       ub_checks.rs:68
    11.16%  range.rs           range.rs:204
     6.39%  range.rs           range.rs:0
     4.61%  range.rs           range.rs:849
     3.78%  code_with_type.rs  code_with_type.rs:13
     3.51%  code_with_type.rs  code_with_type.rs:21
     2.89%  range.rs           range.rs:764
⬢ [acme@toolbx perf-tools-next]$ grep -m1 'model name' /proc/cpuinfo
model name	: AMD Ryzen 9 9950X3D 16-Core Processor
⬢ [acme@toolbx perf-tools-next]$ uname -a
Linux toolbx 6.18.8-200.fc43.x86_64 #1 SMP PREEMPT_DYNAMIC Fri Jan 30 20:23:28 UTC 2026 x86_64 GNU/Linux
⬢ [acme@toolbx perf-tools-next]$

  root@number:~# perf test 'perf data type profiling tests'
   83: perf data type profiling tests                                  : Ok
  root@number:~# perf test -vv 'perf data type profiling tests'
   83: perf data type profiling tests:
  --- start ---
  test child forked, pid 125028
  Basic Rust perf annotate test
  Basic annotate test [Success]
  Pipe Rust perf annotate test
  Pipe annotate test [Success]
  Basic C perf annotate test
  Basic annotate test [Success]
  Pipe C perf annotate test
  Pipe annotate test [Success]
  ---- end(0) ----
   83: perf data type profiling tests                                  : Ok
  root@number:~#

Thanks, applied to perf-tools-next,

- Arnaldo

- Arnaldo
 
> Dmitrii Dolgov (4):
>   tools/build: Add a feature test for rust compiler
>   perf test workload: Add code_with_type test workload
>   perf tests: Test annotate with data type profiling and rust
>   perf tests: Test annotate with data type profiling and C
> 
>  tools/build/Makefile.build                    | 14 ++++
>  tools/build/Makefile.feature                  |  6 +-
>  tools/build/feature/Makefile                  |  7 ++
>  tools/build/feature/test-rust.rs              |  4 +
>  tools/perf/Makefile.config                    | 11 +++
>  tools/perf/Makefile.perf                      |  2 +-
>  tools/perf/builtin-check.c                    |  1 +
>  tools/perf/tests/builtin-test.c               |  4 +
>  tools/perf/tests/shell/data_type_profiling.sh | 84 +++++++++++++++++++
>  tools/perf/tests/tests.h                      |  4 +
>  tools/perf/tests/workloads/Build              |  5 ++
>  tools/perf/tests/workloads/code_with_type.c   | 46 ++++++++++
>  tools/perf/tests/workloads/code_with_type.rs  | 23 +++++
>  tools/scripts/Makefile.include                |  2 +
>  14 files changed, 210 insertions(+), 3 deletions(-)
>  create mode 100644 tools/build/feature/test-rust.rs
>  create mode 100755 tools/perf/tests/shell/data_type_profiling.sh
>  create mode 100644 tools/perf/tests/workloads/code_with_type.c
>  create mode 100644 tools/perf/tests/workloads/code_with_type.rs
> 
> 
> base-commit: 36a1b0061a584430277861fe5d8bd107aef26137
> -- 
> 2.52.0
> 

Rust data-type profiling working in perf was: Re: [RFC PATCH v2 0/4] Test annotate with data type profiling

[Arnaldo Carvalho de Melo]

On Sun, Feb 08, 2026 at 11:39:28AM -0300, Arnaldo Carvalho de Melo wrote:
> On Sun, Feb 08, 2026 at 01:22:22PM +0100, Dmitrii Dolgov wrote:
> > Add shell tests for data type profiling, including C and rust.

> > To support the rust test, a new workload with rust code was introduced.
> > To build it only when rust is actually available, also add a feature
> > test for rust compiler and guard everything behind it.

> > Changes in v2:
> > - Switched to use mem record.
> > - Fixed the build issue with a custom output.
> > - Separated patches for the workload and tests.
> > - Added new test for C code.
> > - Added a feature test for rust compiler.
 
> Thanks, tested it, everything working as advertised:

This is an interesting piece of news, so CCing to lkml and Miguel as
well, please CC that list in the future.

Also please consider adding examples of output of such new features, so
that people can quickly see it in action, data-type profiling for Rust
seems interesting, right? :-)

- Arnaldo
 
> ⬢ [acme@toolbx perf-tools-next]$ m
> make: Entering directory '/home/acme/git/linux/tools/perf'
>   BUILD:   Doing 'make -j32' parallel build
> Warning: Kernel ABI header differences:
>   diff -u tools/arch/arm64/include/asm/cputype.h arch/arm64/include/asm/cputype.h
>   diff -u tools/perf/arch/s390/entry/syscalls/syscall.tbl arch/s390/kernel/syscalls/syscall.tbl
> 
> Auto-detecting system features:
> ...                  libdw: [ on  ]
> ...                  glibc: [ on  ]
> ...                 libelf: [ on  ]
> ...                libnuma: [ on  ]
> ... numa_num_possible_cpus: [ on  ]
> ...              libpython: [ on  ]
> ...            libcapstone: [ on  ]
> ...              llvm-perf: [ on  ]
> ...                   zlib: [ on  ]
> ...                   lzma: [ on  ]
> ...                    bpf: [ on  ]
> ...                 libaio: [ on  ]
> ...                libzstd: [ on  ]
> ...             libopenssl: [ on  ]
> ...                   rust: [ on  ] <-------------------------
> 
>   INSTALL libsubcmd_headers
> <SNIP>
> 
> ⬢ [acme@toolbx perf-tools-next]$ perf record perf test -w code_with_type
> [ perf record: Woken up 2 times to write data ]
> [ perf record: Captured and wrote 0.162 MB perf.data (4036 samples) ]
> ⬢ [acme@toolbx perf-tools-next]$ perf report --stdio --dso perf -s srcfile,srcline | head -20
> # To display the perf.data header info, please use --header/--header-only options.
> #
> #
> # Total Lost Samples: 0
> #
> # Samples: 4K of event 'cpu/cycles/Pu'
> # Event count (approx.): 5337677712
> #
> # Overhead  Source File        Source:Line
> # ........  .................  ..............................................................
> #
>     25.53%  cmp.rs             cmp.rs:1903
>     16.66%  code_with_type.rs  code_with_type.rs:15
>     14.48%  ub_checks.rs       ub_checks.rs:68
>     11.16%  range.rs           range.rs:204
>      6.39%  range.rs           range.rs:0
>      4.61%  range.rs           range.rs:849
>      3.78%  code_with_type.rs  code_with_type.rs:13
>      3.51%  code_with_type.rs  code_with_type.rs:21
>      2.89%  range.rs           range.rs:764
> ⬢ [acme@toolbx perf-tools-next]$ grep -m1 'model name' /proc/cpuinfo
> model name	: AMD Ryzen 9 9950X3D 16-Core Processor
> ⬢ [acme@toolbx perf-tools-next]$ uname -a
> Linux toolbx 6.18.8-200.fc43.x86_64 #1 SMP PREEMPT_DYNAMIC Fri Jan 30 20:23:28 UTC 2026 x86_64 GNU/Linux
> ⬢ [acme@toolbx perf-tools-next]$
> 
>   root@number:~# perf test 'perf data type profiling tests'
>    83: perf data type profiling tests                                  : Ok
>   root@number:~# perf test -vv 'perf data type profiling tests'
>    83: perf data type profiling tests:
>   --- start ---
>   test child forked, pid 125028
>   Basic Rust perf annotate test
>   Basic annotate test [Success]
>   Pipe Rust perf annotate test
>   Pipe annotate test [Success]
>   Basic C perf annotate test
>   Basic annotate test [Success]
>   Pipe C perf annotate test
>   Pipe annotate test [Success]
>   ---- end(0) ----
>    83: perf data type profiling tests                                  : Ok
>   root@number:~#
> 
> Thanks, applied to perf-tools-next,
> 
> - Arnaldo

> > Dmitrii Dolgov (4):
> >   tools/build: Add a feature test for rust compiler
> >   perf test workload: Add code_with_type test workload
> >   perf tests: Test annotate with data type profiling and rust
> >   perf tests: Test annotate with data type profiling and C
> > 
> >  tools/build/Makefile.build                    | 14 ++++
> >  tools/build/Makefile.feature                  |  6 +-
> >  tools/build/feature/Makefile                  |  7 ++
> >  tools/build/feature/test-rust.rs              |  4 +
> >  tools/perf/Makefile.config                    | 11 +++
> >  tools/perf/Makefile.perf                      |  2 +-
> >  tools/perf/builtin-check.c                    |  1 +
> >  tools/perf/tests/builtin-test.c               |  4 +
> >  tools/perf/tests/shell/data_type_profiling.sh | 84 +++++++++++++++++++
> >  tools/perf/tests/tests.h                      |  4 +
> >  tools/perf/tests/workloads/Build              |  5 ++
> >  tools/perf/tests/workloads/code_with_type.c   | 46 ++++++++++
> >  tools/perf/tests/workloads/code_with_type.rs  | 23 +++++
> >  tools/scripts/Makefile.include                |  2 +
> >  14 files changed, 210 insertions(+), 3 deletions(-)
> >  create mode 100644 tools/build/feature/test-rust.rs
> >  create mode 100755 tools/perf/tests/shell/data_type_profiling.sh
> >  create mode 100644 tools/perf/tests/workloads/code_with_type.c
> >  create mode 100644 tools/perf/tests/workloads/code_with_type.rs
> > 
> > base-commit: 36a1b0061a584430277861fe5d8bd107aef26137
> > -- 
> > 2.52.0
> > 

Re: Rust data-type profiling working in perf was: Re: [RFC PATCH v2 0/4] Test annotate with data type profiling

[Miguel Ojeda]

On Sun, Feb 8, 2026 at 3:42 PM Arnaldo Carvalho de Melo <acme@kernel.org> wrote:
>
> This is an interesting piece of news, so CCing to lkml and Miguel as
> well, please CC that list in the future.
>
> Also please consider adding examples of output of such new features, so
> that people can quickly see it in action, data-type profiling for Rust
> seems interesting, right? :-)

Thanks Arnaldo for the ping!

Cc'ing rust-for-linux as well.

Thread at https://lore.kernel.org/all/20260208122227.3524-1-9erthalion6@gmail.com/

Cheers,
Miguel

Re: Rust data-type profiling working in perf was: Re: [RFC PATCH v2 0/4] Test annotate with data type profiling

[Dmitry Dolgov]

> On Sun, Feb 08, 2026 at 11:42:28AM -0300, Arnaldo Carvalho de Melo wrote:
>
> Also please consider adding examples of output of such new features, so
> that people can quickly see it in action, data-type profiling for Rust
> seems interesting, right? :-)

Agree :) What would be the right place to put such examples, somewhere
in the documentation?

Re: [RFC PATCH v2 2/4] perf test workload: Add code_with_type test workload

[Ian Rogers]

On Sun, Feb 8, 2026 at 4:22 AM Dmitrii Dolgov <9erthalion6@gmail.com> wrote:
>
> The purpose of the workload is to gather samples of rust runtime. To
> achiever that it has a dummy rust library linked with it. Per
> recommendations for such scenarios [1], the rust library is statically
> linked.
>
> An example:
>
> $ perf record perf test -w code_with_type
> [ perf record: Woken up 1 times to write data ]
> [ perf record: Captured and wrote 0.160 MB perf.data (4074 samples) ]
>
> $ perf report --stdio --dso perf -s srcfile,srcline
>     45.16%  ub_checks.rs       ub_checks.rs:72
>      6.72%  code_with_type.rs  code_with_type.rs:15
>      6.64%  range.rs           range.rs:767
>      4.26%  code_with_type.rs  code_with_type.rs:21
>      4.23%  range.rs           range.rs:0
>      3.99%  code_with_type.rs  code_with_type.rs:16
>     [...]
>
> [1]: https://doc.rust-lang.org/reference/linkage.html#mixed-rust-and-foreign-codebases
>
> Signed-off-by: Dmitrii Dolgov <9erthalion6@gmail.com>
> ---
>  tools/build/Makefile.build                   | 14 ++++++
>  tools/perf/Makefile.perf                     |  2 +-
>  tools/perf/tests/builtin-test.c              |  4 ++
>  tools/perf/tests/tests.h                     |  4 ++
>  tools/perf/tests/workloads/Build             |  5 +++
>  tools/perf/tests/workloads/code_with_type.c  | 46 ++++++++++++++++++++
>  tools/perf/tests/workloads/code_with_type.rs | 23 ++++++++++
>  tools/scripts/Makefile.include               |  2 +
>  8 files changed, 99 insertions(+), 1 deletion(-)
>  create mode 100644 tools/perf/tests/workloads/code_with_type.c
>  create mode 100644 tools/perf/tests/workloads/code_with_type.rs
>
> diff --git a/tools/build/Makefile.build b/tools/build/Makefile.build
> index 3584ff30860..60e65870eae 100644
> --- a/tools/build/Makefile.build
> +++ b/tools/build/Makefile.build
> @@ -76,6 +76,14 @@ quiet_cmd_host_ld_multi = HOSTLD  $@
>        cmd_host_ld_multi = $(if $(strip $(obj-y)),\
>                            $(HOSTLD) -r -o $@  $(filter $(obj-y),$^),rm -f $@; $(HOSTAR) rcs $@)
>
> +rust_common_cmd = \
> +       $(RUSTC) $(rust_flags) \
> +       --crate-type staticlib -L $(objtree)/rust/ \
> +       --emit=dep-info=$(depfile),link

Does this need to be cross compilation aware? I worry that we can
detect local Rust support but not have cross compilation support and
then perf tool cross compilation builds are broken.

Thanks,
Ian

> +
> +quiet_cmd_rustc_a_rs = $(RUSTC) $(quiet_modtag) $@
> +      cmd_rustc_a_rs = $(rust_common_cmd) -o $@ -g $< $(cmd_objtool)
> +
>  ifneq ($(filter $(obj),$(hostprogs)),)
>    host = host_
>  endif
> @@ -105,6 +113,12 @@ $(OUTPUT)%.s: %.c FORCE
>         $(call rule_mkdir)
>         $(call if_changed_dep,cc_s_c)
>
> +# it's recommended to build a static rust library, when a foreight (to rust)
> +# linker is used.
> +$(OUTPUT)%.a: %.rs FORCE
> +       $(call rule_mkdir)
> +       $(call if_changed_dep,rustc_a_rs)
> +
>  # bison and flex files are generated in the OUTPUT directory
>  # so it needs a separate rule to depend on them properly
>  $(OUTPUT)%-bison.o: $(OUTPUT)%-bison.c FORCE
> diff --git a/tools/perf/Makefile.perf b/tools/perf/Makefile.perf
> index 2a7e5814b15..a6d8ca3e923 100644
> --- a/tools/perf/Makefile.perf
> +++ b/tools/perf/Makefile.perf
> @@ -271,7 +271,7 @@ ifeq ($(PYLINT),1)
>    PYLINT := $(shell which pylint 2> /dev/null)
>  endif
>
> -export srctree OUTPUT RM CC CXX LD AR CFLAGS CXXFLAGS V BISON FLEX AWK
> +export srctree OUTPUT RM CC CXX RUSTC LD AR CFLAGS CXXFLAGS V BISON FLEX AWK
>  export HOSTCC HOSTLD HOSTAR HOSTCFLAGS SHELLCHECK MYPY PYLINT
>
>  include $(srctree)/tools/build/Makefile.include
> diff --git a/tools/perf/tests/builtin-test.c b/tools/perf/tests/builtin-test.c
> index e2490652f03..06507066213 100644
> --- a/tools/perf/tests/builtin-test.c
> +++ b/tools/perf/tests/builtin-test.c
> @@ -154,6 +154,10 @@ static struct test_workload *workloads[] = {
>         &workload__landlock,
>         &workload__traploop,
>         &workload__inlineloop,
> +
> +#ifdef HAVE_RUST_SUPPORT
> +       &workload__code_with_type,
> +#endif
>  };
>
>  #define workloads__for_each(workload) \
> diff --git a/tools/perf/tests/tests.h b/tools/perf/tests/tests.h
> index 1f0f8b267fb..f5f1238d1f7 100644
> --- a/tools/perf/tests/tests.h
> +++ b/tools/perf/tests/tests.h
> @@ -242,6 +242,10 @@ DECLARE_WORKLOAD(landlock);
>  DECLARE_WORKLOAD(traploop);
>  DECLARE_WORKLOAD(inlineloop);
>
> +#ifdef HAVE_RUST_SUPPORT
> +DECLARE_WORKLOAD(code_with_type);
> +#endif
> +
>  extern const char *dso_to_test;
>  extern const char *test_objdump_path;
>
> diff --git a/tools/perf/tests/workloads/Build b/tools/perf/tests/workloads/Build
> index 866a00bd14a..2ef97f7affc 100644
> --- a/tools/perf/tests/workloads/Build
> +++ b/tools/perf/tests/workloads/Build
> @@ -10,6 +10,11 @@ perf-test-y += landlock.o
>  perf-test-y += traploop.o
>  perf-test-y += inlineloop.o
>
> +ifeq ($(CONFIG_RUST_SUPPORT),y)
> +    perf-test-y += code_with_type.o
> +    perf-test-y += code_with_type.a
> +endif
> +
>  CFLAGS_sqrtloop.o         = -g -O0 -fno-inline -U_FORTIFY_SOURCE
>  CFLAGS_leafloop.o         = -g -O0 -fno-inline -fno-omit-frame-pointer -U_FORTIFY_SOURCE
>  CFLAGS_brstack.o          = -g -O0 -fno-inline -U_FORTIFY_SOURCE
> diff --git a/tools/perf/tests/workloads/code_with_type.c b/tools/perf/tests/workloads/code_with_type.c
> new file mode 100644
> index 00000000000..65d7be7dac2
> --- /dev/null
> +++ b/tools/perf/tests/workloads/code_with_type.c
> @@ -0,0 +1,46 @@
> +// SPDX-License-Identifier: GPL-2.0
> +#include <pthread.h>
> +#include <stdlib.h>
> +#include <signal.h>
> +#include <unistd.h>
> +#include <linux/compiler.h>
> +#include "../tests.h"
> +
> +extern void test_rs(uint count);
> +
> +static volatile sig_atomic_t done;
> +
> +static void sighandler(int sig __maybe_unused)
> +{
> +       done = 1;
> +}
> +
> +static int code_with_type(int argc, const char **argv)
> +{
> +       int sec = 1, num_loops = 100;
> +
> +       pthread_setname_np(pthread_self(), "perf-code-with-type");
> +       if (argc > 0)
> +               sec = atoi(argv[0]);
> +
> +       if (argc > 1)
> +               num_loops = atoi(argv[1]);
> +
> +       signal(SIGINT, sighandler);
> +       signal(SIGALRM, sighandler);
> +       alarm(sec);
> +
> +       /*
> +        * Rust doesn't have signal management in the standard library. To
> +        * not deal with any external crates, offload signal handling to the
> +        * outside code.
> +        */
> +       while (!done) {
> +               test_rs(num_loops);
> +               continue;
> +       }
> +
> +       return 0;
> +}
> +
> +DEFINE_WORKLOAD(code_with_type);
> diff --git a/tools/perf/tests/workloads/code_with_type.rs b/tools/perf/tests/workloads/code_with_type.rs
> new file mode 100644
> index 00000000000..3b91e51919d
> --- /dev/null
> +++ b/tools/perf/tests/workloads/code_with_type.rs
> @@ -0,0 +1,23 @@
> +// SPDX-License-Identifier: GPL-2.0
> +
> +// We're going to look for this structure in the data type profiling report
> +#[allow(dead_code)]
> +struct Buf {
> +    data1: u64,
> +    data2: String,
> +    data3: u64,
> +}
> +
> +#[no_mangle]
> +pub extern "C" fn test_rs(count: u32) {
> +    let mut b =  Buf { data1: 0, data2: String::from("data"), data3: 0};
> +
> +    for _ in 1..count {
> +        b.data1 += 1;
> +        if b.data1 == 123 {
> +            b.data1 += 1;
> +        }
> +
> +        b.data3 += b.data1;
> +    }
> +}
> diff --git a/tools/scripts/Makefile.include b/tools/scripts/Makefile.include
> index ded48263dd5..b5ecf137feb 100644
> --- a/tools/scripts/Makefile.include
> +++ b/tools/scripts/Makefile.include
> @@ -94,6 +94,8 @@ LLVM_STRIP    ?= llvm-strip
>  # Some tools require bpftool
>  SYSTEM_BPFTOOL ?= bpftool
>
> +RUSTC          ?= rustc
> +
>  ifeq ($(CC_NO_CLANG), 1)
>  EXTRA_WARNINGS += -Wstrict-aliasing=3
>
> --
> 2.52.0
>

Re: [RFC PATCH v2 2/4] perf test workload: Add code_with_type test workload

[Ian Rogers]

On Sun, Feb 8, 2026 at 4:22 AM Dmitrii Dolgov <9erthalion6@gmail.com> wrote:
>
> The purpose of the workload is to gather samples of rust runtime. To
> achiever that it has a dummy rust library linked with it. Per
> recommendations for such scenarios [1], the rust library is statically
> linked.
>
> An example:
>
> $ perf record perf test -w code_with_type
> [ perf record: Woken up 1 times to write data ]
> [ perf record: Captured and wrote 0.160 MB perf.data (4074 samples) ]
>
> $ perf report --stdio --dso perf -s srcfile,srcline
>     45.16%  ub_checks.rs       ub_checks.rs:72
>      6.72%  code_with_type.rs  code_with_type.rs:15
>      6.64%  range.rs           range.rs:767
>      4.26%  code_with_type.rs  code_with_type.rs:21
>      4.23%  range.rs           range.rs:0
>      3.99%  code_with_type.rs  code_with_type.rs:16
>     [...]
>
> [1]: https://doc.rust-lang.org/reference/linkage.html#mixed-rust-and-foreign-codebases
>
> Signed-off-by: Dmitrii Dolgov <9erthalion6@gmail.com>
> ---
>  tools/build/Makefile.build                   | 14 ++++++
>  tools/perf/Makefile.perf                     |  2 +-
>  tools/perf/tests/builtin-test.c              |  4 ++
>  tools/perf/tests/tests.h                     |  4 ++
>  tools/perf/tests/workloads/Build             |  5 +++
>  tools/perf/tests/workloads/code_with_type.c  | 46 ++++++++++++++++++++
>  tools/perf/tests/workloads/code_with_type.rs | 23 ++++++++++
>  tools/scripts/Makefile.include               |  2 +
>  8 files changed, 99 insertions(+), 1 deletion(-)
>  create mode 100644 tools/perf/tests/workloads/code_with_type.c
>  create mode 100644 tools/perf/tests/workloads/code_with_type.rs
>
> diff --git a/tools/build/Makefile.build b/tools/build/Makefile.build
> index 3584ff30860..60e65870eae 100644
> --- a/tools/build/Makefile.build
> +++ b/tools/build/Makefile.build
> @@ -76,6 +76,14 @@ quiet_cmd_host_ld_multi = HOSTLD  $@
>        cmd_host_ld_multi = $(if $(strip $(obj-y)),\
>                            $(HOSTLD) -r -o $@  $(filter $(obj-y),$^),rm -f $@; $(HOSTAR) rcs $@)
>
> +rust_common_cmd = \
> +       $(RUSTC) $(rust_flags) \
> +       --crate-type staticlib -L $(objtree)/rust/ \
> +       --emit=dep-info=$(depfile),link
> +
> +quiet_cmd_rustc_a_rs = $(RUSTC) $(quiet_modtag) $@
> +      cmd_rustc_a_rs = $(rust_common_cmd) -o $@ -g $< $(cmd_objtool)
> +
>  ifneq ($(filter $(obj),$(hostprogs)),)
>    host = host_
>  endif
> @@ -105,6 +113,12 @@ $(OUTPUT)%.s: %.c FORCE
>         $(call rule_mkdir)
>         $(call if_changed_dep,cc_s_c)
>
> +# it's recommended to build a static rust library, when a foreight (to rust)
> +# linker is used.
> +$(OUTPUT)%.a: %.rs FORCE
> +       $(call rule_mkdir)
> +       $(call if_changed_dep,rustc_a_rs)
> +
>  # bison and flex files are generated in the OUTPUT directory
>  # so it needs a separate rule to depend on them properly
>  $(OUTPUT)%-bison.o: $(OUTPUT)%-bison.c FORCE
> diff --git a/tools/perf/Makefile.perf b/tools/perf/Makefile.perf
> index 2a7e5814b15..a6d8ca3e923 100644
> --- a/tools/perf/Makefile.perf
> +++ b/tools/perf/Makefile.perf
> @@ -271,7 +271,7 @@ ifeq ($(PYLINT),1)
>    PYLINT := $(shell which pylint 2> /dev/null)
>  endif
>
> -export srctree OUTPUT RM CC CXX LD AR CFLAGS CXXFLAGS V BISON FLEX AWK
> +export srctree OUTPUT RM CC CXX RUSTC LD AR CFLAGS CXXFLAGS V BISON FLEX AWK
>  export HOSTCC HOSTLD HOSTAR HOSTCFLAGS SHELLCHECK MYPY PYLINT
>
>  include $(srctree)/tools/build/Makefile.include
> diff --git a/tools/perf/tests/builtin-test.c b/tools/perf/tests/builtin-test.c
> index e2490652f03..06507066213 100644
> --- a/tools/perf/tests/builtin-test.c
> +++ b/tools/perf/tests/builtin-test.c
> @@ -154,6 +154,10 @@ static struct test_workload *workloads[] = {
>         &workload__landlock,
>         &workload__traploop,
>         &workload__inlineloop,
> +
> +#ifdef HAVE_RUST_SUPPORT
> +       &workload__code_with_type,
> +#endif
>  };
>
>  #define workloads__for_each(workload) \
> diff --git a/tools/perf/tests/tests.h b/tools/perf/tests/tests.h
> index 1f0f8b267fb..f5f1238d1f7 100644
> --- a/tools/perf/tests/tests.h
> +++ b/tools/perf/tests/tests.h
> @@ -242,6 +242,10 @@ DECLARE_WORKLOAD(landlock);
>  DECLARE_WORKLOAD(traploop);
>  DECLARE_WORKLOAD(inlineloop);
>
> +#ifdef HAVE_RUST_SUPPORT
> +DECLARE_WORKLOAD(code_with_type);
> +#endif
> +
>  extern const char *dso_to_test;
>  extern const char *test_objdump_path;
>
> diff --git a/tools/perf/tests/workloads/Build b/tools/perf/tests/workloads/Build
> index 866a00bd14a..2ef97f7affc 100644
> --- a/tools/perf/tests/workloads/Build
> +++ b/tools/perf/tests/workloads/Build
> @@ -10,6 +10,11 @@ perf-test-y += landlock.o
>  perf-test-y += traploop.o
>  perf-test-y += inlineloop.o
>
> +ifeq ($(CONFIG_RUST_SUPPORT),y)
> +    perf-test-y += code_with_type.o
> +    perf-test-y += code_with_type.a

nit: It'd be more normal to write this as:
perf-test-$(CONFIG_RUST_SUPPORT) += code_with_type.o
perf-test-$(CONFIG_RUST_SUPPORT) += code_with_type.a

I did an update this morning but found I needed to install rustc to
get the build working. I'm not sure things work without rustc
installed as advertised.

Thanks,
Ian

> +endif
> +
>  CFLAGS_sqrtloop.o         = -g -O0 -fno-inline -U_FORTIFY_SOURCE
>  CFLAGS_leafloop.o         = -g -O0 -fno-inline -fno-omit-frame-pointer -U_FORTIFY_SOURCE
>  CFLAGS_brstack.o          = -g -O0 -fno-inline -U_FORTIFY_SOURCE
> diff --git a/tools/perf/tests/workloads/code_with_type.c b/tools/perf/tests/workloads/code_with_type.c
> new file mode 100644
> index 00000000000..65d7be7dac2
> --- /dev/null
> +++ b/tools/perf/tests/workloads/code_with_type.c
> @@ -0,0 +1,46 @@
> +// SPDX-License-Identifier: GPL-2.0
> +#include <pthread.h>
> +#include <stdlib.h>
> +#include <signal.h>
> +#include <unistd.h>
> +#include <linux/compiler.h>
> +#include "../tests.h"
> +
> +extern void test_rs(uint count);
> +
> +static volatile sig_atomic_t done;
> +
> +static void sighandler(int sig __maybe_unused)
> +{
> +       done = 1;
> +}
> +
> +static int code_with_type(int argc, const char **argv)
> +{
> +       int sec = 1, num_loops = 100;
> +
> +       pthread_setname_np(pthread_self(), "perf-code-with-type");
> +       if (argc > 0)
> +               sec = atoi(argv[0]);
> +
> +       if (argc > 1)
> +               num_loops = atoi(argv[1]);
> +
> +       signal(SIGINT, sighandler);
> +       signal(SIGALRM, sighandler);
> +       alarm(sec);
> +
> +       /*
> +        * Rust doesn't have signal management in the standard library. To
> +        * not deal with any external crates, offload signal handling to the
> +        * outside code.
> +        */
> +       while (!done) {
> +               test_rs(num_loops);
> +               continue;
> +       }
> +
> +       return 0;
> +}
> +
> +DEFINE_WORKLOAD(code_with_type);
> diff --git a/tools/perf/tests/workloads/code_with_type.rs b/tools/perf/tests/workloads/code_with_type.rs
> new file mode 100644
> index 00000000000..3b91e51919d
> --- /dev/null
> +++ b/tools/perf/tests/workloads/code_with_type.rs
> @@ -0,0 +1,23 @@
> +// SPDX-License-Identifier: GPL-2.0
> +
> +// We're going to look for this structure in the data type profiling report
> +#[allow(dead_code)]
> +struct Buf {
> +    data1: u64,
> +    data2: String,
> +    data3: u64,
> +}
> +
> +#[no_mangle]
> +pub extern "C" fn test_rs(count: u32) {
> +    let mut b =  Buf { data1: 0, data2: String::from("data"), data3: 0};
> +
> +    for _ in 1..count {
> +        b.data1 += 1;
> +        if b.data1 == 123 {
> +            b.data1 += 1;
> +        }
> +
> +        b.data3 += b.data1;
> +    }
> +}
> diff --git a/tools/scripts/Makefile.include b/tools/scripts/Makefile.include
> index ded48263dd5..b5ecf137feb 100644
> --- a/tools/scripts/Makefile.include
> +++ b/tools/scripts/Makefile.include
> @@ -94,6 +94,8 @@ LLVM_STRIP    ?= llvm-strip
>  # Some tools require bpftool
>  SYSTEM_BPFTOOL ?= bpftool
>
> +RUSTC          ?= rustc
> +
>  ifeq ($(CC_NO_CLANG), 1)
>  EXTRA_WARNINGS += -Wstrict-aliasing=3
>
> --
> 2.52.0
>

Re: Rust data-type profiling working in perf was: Re: [RFC PATCH v2 0/4] Test annotate with data type profiling

[Namhyung Kim]

On Mon, Feb 09, 2026 at 09:45:32AM +0100, Dmitry Dolgov wrote:
> > On Sun, Feb 08, 2026 at 11:42:28AM -0300, Arnaldo Carvalho de Melo wrote:
> >
> > Also please consider adding examples of output of such new features, so
> > that people can quickly see it in action, data-type profiling for Rust
> > seems interesting, right? :-)
> 
> Agree :) What would be the right place to put such examples, somewhere
> in the documentation?

Yep, please add it to the documentation.

Thanks,
Namhyung

Re: [RFC PATCH v2 4/4] perf tests: Test annotate with data type profiling and C

[Ian Rogers]

On Sun, Feb 8, 2026 at 4:23 AM Dmitrii Dolgov <9erthalion6@gmail.com> wrote:
>
> Exercise the annotate command with data type profiling feature with C. For that
> extend the existing data type profiling shell test to profile the datasym
> workload, then annotate the result expecting to see some data structures from
> the C code.
>
> Signed-off-by: Dmitrii Dolgov <9erthalion6@gmail.com>
> ---
>  tools/perf/tests/shell/data_type_profiling.sh | 31 ++++++++++++++-----
>  1 file changed, 23 insertions(+), 8 deletions(-)
>
> diff --git a/tools/perf/tests/shell/data_type_profiling.sh b/tools/perf/tests/shell/data_type_profiling.sh
> index cdc9adb7d70..a230f5d4c42 100755
> --- a/tools/perf/tests/shell/data_type_profiling.sh
> +++ b/tools/perf/tests/shell/data_type_profiling.sh
> @@ -6,12 +6,14 @@ set -e
>
>  # The logic below follows the same line as the annotate test, but looks for a
>  # data type profiling manifestation
> -testtype="# data-type: struct Buf"
> +
> +# Values in testtypes and testprogs should match
> +testtypes=("# data-type: struct Buf" "# data-type: struct _buf")

So in the datasym workload the struct _buf is a typedef and the value
declared to be of the type of the typedef:
https://web.git.kernel.org/pub/scm/linux/kernel/git/perf/perf-tools-next.git/tree/tools/perf/tests/workloads/datasym.c?h=perf-tools-next#n14
```
typedef struct _buf {
char data1;
char reserved[55];
char data2;
} buf __attribute__((aligned(64)));

/* volatile to try to avoid the compiler seeing reserved as unused. */
static volatile buf workload_datasym_buf1 = {
/* to have this in the data section */
.reserved[0] = 1,
};
```
This test is failing for me as I see "data-type: buf" rather than
"data-type: struct _buf" (ie the typedef rather than the struct):
```
    0.00 :   201290:        movzbl  0xbb5869(%rip), %eax  # 0xdb6b00
<workload_datasym_buf1>               # data-type: buf +0 (data1)
    0.00 :   201297:        addl    $0x1, %eax
   47.66 :   20129a:        movb    %al, 0xbb5860(%rip)  # 0xdb6b00
<workload_datasym_buf1>                # data-type: buf +0 (data1)
    0.00 :   2012a0:        movzbl  0xbb5859(%rip), %eax  # 0xdb6b00
<workload_datasym_buf1>               # data-type: buf +0 (data1)
    0.00 :   2012a7:        cmpb    $0x7b, %al
    0.00 :   2012a9:        jne     0x2012bb <datasym+0x9c>
    0.00 :   2012ab:        movzbl  0xbb584e(%rip), %eax  # 0xdb6b00
<workload_datasym_buf1>               # data-type: buf +0 (data1)
    0.00 :   2012b2:        addl    $0x1, %eax
    0.25 :   2012b5:        movb    %al, 0xbb5845(%rip)  # 0xdb6b00
<workload_datasym_buf1>                # data-type: buf +0 (data1)
    0.00 :   2012bb:        movzbl  0xbb583e(%rip), %eax  # 0xdb6b00
<workload_datasym_buf1>               # data-type: buf +0 (data1)
    0.00 :   2012c2:        movzbl  0xbb586f(%rip), %edx  # 0xdb6b38
<workload_datasym_buf1+0x38>                  # data-type: buf +0x38
(data2)
    0.00 :   2012c9:        addl    %edx, %eax
   52.10 :   2012cb:        movb    %al, 0xbb5867(%rip)  # 0xdb6b38
<workload_datasym_buf1+0x38>                   # data-type: buf +0x38
(data2)
    0.00 :   2012d1:        movl    0xbc7861(%rip), %eax  # 0xdc8b38
<done>             # data-type: sig_atomic_t +0
```
It seems the typedef is a more accurate type name, so I think the test
is wrong here.

Thanks,
Ian

> +testprogs=("perf test -w code_with_type" "perf test -w datasym")
>
>  err=0
>  perfdata=$(mktemp /tmp/__perf_test.perf.data.XXXXX)
>  perfout=$(mktemp /tmp/__perf_test.perf.out.XXXXX)
> -testprog="perf test -w code_with_type"
>
>  cleanup() {
>    rm -rf "${perfdata}" "${perfout}"
> @@ -29,12 +31,23 @@ trap trap_cleanup EXIT TERM INT
>
>  test_basic_annotate() {
>    mode=$1
> -  echo "${mode} perf annotate test"
> +  runtime=$2
> +
> +  echo "${mode} ${runtime} perf annotate test"
> +
> +  case "x${runtime}" in
> +    "xRust")
> +    index=0 ;;
> +
> +    "xC")
> +    index=1 ;;
> +  esac
> +
>    if [ "x${mode}" == "xBasic" ]
>    then
> -    perf mem record -o "${perfdata}" ${testprog} 2> /dev/null
> +    perf mem record -o "${perfdata}" ${testprogs[$index]} 2> /dev/null
>    else
> -    perf mem record -o - ${testprog} 2> /dev/null > "${perfdata}"
> +    perf mem record -o - ${testprogs[$index]} 2> /dev/null > "${perfdata}"
>    fi
>    if [ "x$?" != "x0" ]
>    then
> @@ -52,7 +65,7 @@ test_basic_annotate() {
>    fi
>
>    # check if it has the target data type
> -  if ! grep -q "${testtype}" "${perfout}"
> +  if ! grep -q "${testtypes[$index]}" "${perfout}"
>    then
>      echo "${mode} annotate [Failed: missing target data type]"
>      cat "${perfout}"
> @@ -62,8 +75,10 @@ test_basic_annotate() {
>    echo "${mode} annotate test [Success]"
>  }
>
> -test_basic_annotate Basic
> -test_basic_annotate Pipe
> +test_basic_annotate Basic Rust
> +test_basic_annotate Pipe Rust
> +test_basic_annotate Basic C
> +test_basic_annotate Pipe C
>
>  cleanup
>  exit $err
> --
> 2.52.0
>

Re: [RFC PATCH v2 4/4] perf tests: Test annotate with data type profiling and C

[Dmitry Dolgov]

> On Mon, Feb 09, 2026 at 09:39:09PM -0800, Ian Rogers wrote:
> >  # The logic below follows the same line as the annotate test, but looks for a
> >  # data type profiling manifestation
> > -testtype="# data-type: struct Buf"
> > +
> > +# Values in testtypes and testprogs should match
> > +testtypes=("# data-type: struct Buf" "# data-type: struct _buf")
> 
> So in the datasym workload the struct _buf is a typedef and the value
> declared to be of the type of the typedef:
> https://web.git.kernel.org/pub/scm/linux/kernel/git/perf/perf-tools-next.git/tree/tools/perf/tests/workloads/datasym.c?h=perf-tools-next#n14
> ```
> typedef struct _buf {
> char data1;
> char reserved[55];
> char data2;
> } buf __attribute__((aligned(64)));
> 
> /* volatile to try to avoid the compiler seeing reserved as unused. */
> static volatile buf workload_datasym_buf1 = {
> /* to have this in the data section */
> .reserved[0] = 1,
> };
> ```
> This test is failing for me as I see "data-type: buf" rather than
> "data-type: struct _buf" (ie the typedef rather than the struct):
> ```
>     0.00 :   201290:        movzbl  0xbb5869(%rip), %eax  # 0xdb6b00
> <workload_datasym_buf1>               # data-type: buf +0 (data1)
>     0.00 :   201297:        addl    $0x1, %eax
>    47.66 :   20129a:        movb    %al, 0xbb5860(%rip)  # 0xdb6b00
> <workload_datasym_buf1>                # data-type: buf +0 (data1)
>     0.00 :   2012a0:        movzbl  0xbb5859(%rip), %eax  # 0xdb6b00
> <workload_datasym_buf1>               # data-type: buf +0 (data1)
>     0.00 :   2012a7:        cmpb    $0x7b, %al
>     0.00 :   2012a9:        jne     0x2012bb <datasym+0x9c>
>     0.00 :   2012ab:        movzbl  0xbb584e(%rip), %eax  # 0xdb6b00
> <workload_datasym_buf1>               # data-type: buf +0 (data1)
>     0.00 :   2012b2:        addl    $0x1, %eax
>     0.25 :   2012b5:        movb    %al, 0xbb5845(%rip)  # 0xdb6b00
> <workload_datasym_buf1>                # data-type: buf +0 (data1)
>     0.00 :   2012bb:        movzbl  0xbb583e(%rip), %eax  # 0xdb6b00
> <workload_datasym_buf1>               # data-type: buf +0 (data1)
>     0.00 :   2012c2:        movzbl  0xbb586f(%rip), %edx  # 0xdb6b38
> <workload_datasym_buf1+0x38>                  # data-type: buf +0x38
> (data2)
>     0.00 :   2012c9:        addl    %edx, %eax
>    52.10 :   2012cb:        movb    %al, 0xbb5867(%rip)  # 0xdb6b38
> <workload_datasym_buf1+0x38>                   # data-type: buf +0x38
> (data2)
>     0.00 :   2012d1:        movl    0xbc7861(%rip), %eax  # 0xdc8b38
> <done>             # data-type: sig_atomic_t +0
> ```
> It seems the typedef is a more accurate type name, so I think the test
> is wrong here.

That's interesting, I don't see "data-type: buf" for this particular test, but
I've noticed that "perf annotate" reports different data types (buf vs _buf) in
certain cases. E.g. if as in the test, the data is collected via

    perf mem record

then I get "data-type: struct _buf". But if we do

    perf record

then I get "data-type: buf". Interestingly enough, all the addresses looks the
same, except the final type_die in the end:

	# perf record
	find data type for 0xa00e69(PC) at datasym+0x71
	CU for tests/workloads/datasym.c (die:0x1ddfcf)
	found by addr=0xf7e000 type_offset=0
	 type='buf' size=0x39 (die:0x1de132)
	final result:  type='buf' size=0x39 (die:0x1de132)

	# perf mem record
	find data type for 0xa00e69(PC) at datasym+0x71
	CU for tests/workloads/datasym.c (die:0x1ddfcf)
	found by addr=0xf7e000 type_offset=0
	 type='struct _buf' size=0x39 (die:0x1de0ed)
	final result:  type='struct _buf' size=0x39 (die:0x1de0ed)

Not sure what to make of it, still trying to figure out where it's coming from.

Re: [RFC PATCH v2 2/4] perf test workload: Add code_with_type test workload

[Dmitry Dolgov]

> On Mon, Feb 09, 2026 at 09:33:41AM -0800, Ian Rogers wrote:
>
> I did an update this morning but found I needed to install rustc to
> get the build working. I'm not sure things work without rustc
> installed as advertised.

Yeah, sorry for that. There are few fixes starting from 3f5dfa472ea
(tools build: Fix rust feature detection), which should address this.

Re: [RFC PATCH v2 2/4] perf test workload: Add code_with_type test workload

[Dmitry Dolgov]

> On Mon, Feb 09, 2026 at 09:29:49AM -0800, Ian Rogers wrote:
>
> > +rust_common_cmd = \
> > +       $(RUSTC) $(rust_flags) \
> > +       --crate-type staticlib -L $(objtree)/rust/ \
> > +       --emit=dep-info=$(depfile),link
> 
> Does this need to be cross compilation aware? I worry that we can
> detect local Rust support but not have cross compilation support and
> then perf tool cross compilation builds are broken.

Good point. It's supposed to be cross compilation aware, because
rust_flags must contain the --target argument. But after checking it
out, looks like this variable is not passed from Makefile.perf . I'll
need to fix it, it should be handled similarly to CFLAGS/CXXFLAGS.

[PATCH v1] perf test type profiling: Remote typedef on struct

[Ian Rogers]

The typedef creates an issue where the struct or the typedef may
appear in the output and cause the "perf data type profiling tests" to
fail. Let's remove the typedef to keep the test passing.

Fixes: 335047109d7d ("perf tests: Test annotate with data type profiling and C")
Signed-off-by: Ian Rogers <irogers@google.com>
---
 tools/perf/tests/shell/data_type_profiling.sh | 2 +-
 tools/perf/tests/workloads/datasym.c          | 6 +++---
 2 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/tools/perf/tests/shell/data_type_profiling.sh b/tools/perf/tests/shell/data_type_profiling.sh
index 2a7f8f7c42d0..fb47b7213b33 100755
--- a/tools/perf/tests/shell/data_type_profiling.sh
+++ b/tools/perf/tests/shell/data_type_profiling.sh
@@ -8,7 +8,7 @@ set -e
 # data type profiling manifestation
 
 # Values in testtypes and testprogs should match
-testtypes=("# data-type: struct Buf" "# data-type: struct _buf")
+testtypes=("# data-type: struct Buf" "# data-type: struct buf")
 testprogs=("perf test -w code_with_type" "perf test -w datasym")
 
 err=0
diff --git a/tools/perf/tests/workloads/datasym.c b/tools/perf/tests/workloads/datasym.c
index 1d0b7d64e1ba..19242c7255c0 100644
--- a/tools/perf/tests/workloads/datasym.c
+++ b/tools/perf/tests/workloads/datasym.c
@@ -4,14 +4,14 @@
 #include <linux/compiler.h>
 #include "../tests.h"
 
-typedef struct _buf {
+struct buf {
 	char data1;
 	char reserved[55];
 	char data2;
-} buf __attribute__((aligned(64)));
+} __attribute__((aligned(64)));
 
 /* volatile to try to avoid the compiler seeing reserved as unused. */
-static volatile buf workload_datasym_buf1 = {
+static volatile struct buf workload_datasym_buf1 = {
 	/* to have this in the data section */
 	.reserved[0] = 1,
 };
-- 
2.53.0.473.g4a7958ca14-goog

Re: [PATCH v1] perf test type profiling: Remote typedef on struct

[Dmitry Dolgov]

> On Mon, Mar 02, 2026 at 03:58:21PM -0800, Ian Rogers wrote:
> The typedef creates an issue where the struct or the typedef may
> appear in the output and cause the "perf data type profiling tests" to
> fail. Let's remove the typedef to keep the test passing.

Yes, makes sense to me, thanks. As mentioned in the previous message, it
sounds fishy to me that perf record and perf mem record capture
different data type -- I'll try to get to the bottom of it (I was sort
of hoping to finish the cross compilation topic first, but since it's
not moving that fast, why not do some debugging here).

Reviewed-by: Dmitrii Dolgov <9erthalion6@gmail.com>

Re: [PATCH v1] perf test type profiling: Remote typedef on struct

[Arnaldo Carvalho de Melo]

On Wed, Mar 04, 2026 at 11:44:16AM +0100, Dmitry Dolgov wrote:
> > On Mon, Mar 02, 2026 at 03:58:21PM -0800, Ian Rogers wrote:
> > The typedef creates an issue where the struct or the typedef may
> > appear in the output and cause the "perf data type profiling tests" to
> > fail. Let's remove the typedef to keep the test passing.
> 
> Yes, makes sense to me, thanks. As mentioned in the previous message, it
> sounds fishy to me that perf record and perf mem record capture
> different data type -- I'll try to get to the bottom of it (I was sort
> of hoping to finish the cross compilation topic first, but since it's
> not moving that fast, why not do some debugging here).
> 
> Reviewed-by: Dmitrii Dolgov <9erthalion6@gmail.com>

Thanks, applied to perf-tools, for v7.0.

- Arnaldo

Re: [PATCH v1] perf test type profiling: Remote typedef on struct

[Namhyung Kim]

On Mon, 02 Mar 2026 15:58:21 -0800, Ian Rogers wrote:
> The typedef creates an issue where the struct or the typedef may
> appear in the output and cause the "perf data type profiling tests" to
> fail. Let's remove the typedef to keep the test passing.
> 
> 
Applied to perf-tools-next, thanks!

Best regards,
Namhyung

Re: [PATCH v1] perf test type profiling: Remote typedef on struct

[Arnaldo Carvalho de Melo]

On Wed, Mar 04, 2026 at 01:48:53PM -0800, Namhyung Kim wrote:
> On Mon, 02 Mar 2026 15:58:21 -0800, Ian Rogers wrote:
> > The typedef creates an issue where the struct or the typedef may
> > appear in the output and cause the "perf data type profiling tests" to
> > fail. Let's remove the typedef to keep the test passing.
> > 
> > 
> Applied to perf-tools-next, thanks!

I applied this to perf-tools as well, for now just at tmp.perf-tools
tho.

- Arnaldo