如何使用trace-cmd对自定义Linux内核模块进行函数追踪并生成可分析的输出？

Alright, let's fix your trace-cmd workflow and get that function graph data in a format you can easily analyze with KernelShark or trace-cmd report. The core issue here is mixing up function filters (what you used in sysfs with set_ftrace_filter) and event filters in trace-cmd's arguments.

First: Clarify the Parameter Mapping #

The sysfs set_ftrace_filter you used to isolate my_mod functions maps directly to trace-cmd's -F (uppercase F) parameter, not -f (lowercase, for event filters) or -e (for selecting trace events). That's where most of your earlier errors came from.

Correct trace-cmd Command to Record Function Graphs for Your Module #

Run this command to record only the function calls from your my_mod module, and generate a trace.dat file compatible with KernelShark:

trace-cmd record -p function_graph -F '*:mod:my_mod' cat /dev/my_mod

Let's break this down:

• -p function_graph: Enables the function graph tracer (same as writing function_graph to current_tracer in sysfs).
• -F '*:mod:my_mod': Applies the function filter to only include functions from the my_mod module (exact equivalent of writing *:mod:my_mod to set_ftrace_filter).
• cat /dev/my_mod: Your trigger command to exercise the kernel module (replace this with whatever action triggers your module's code).

Why Your Earlier Commands Failed #

Let's go through the mistakes in your attempts to avoid them in the future:

1. trace-cmd record -f '*:mod:my_mod' -p function_graph ...
   • The -f flag is for event filters, which require you to first specify an event with -e. Since you didn't use -e, trace-cmd throws the "filter must come after event" error.
2. trace-cmd record -e '*:mod:my_mod' -p function_graph ...
   • The -e flag expects a trace event name (like sched:sched_switch or irq:irq_handler_entry), not a function filter syntax. *:mod:my_mod isn't a valid event, hence the "No such file or directory" error.
3. trace-cmd record -e sched -p function_graph -f '*mod:my_mod' ...
   • You tried to apply a function filter syntax as an event filter for the sched events. Event filters use a different syntax (e.g., pid == 1234), so trace-cmd couldn't parse it.
4. trace-cmd record -e irq -p function_graph -f '*:mod:my_mod' ...
   • Again, -f is for event filters, not function filters. The syntax didn't match what trace-cmd expects for irq event filters, so the filter was ignored—hence you got all irq data, not just your module's.

Analyze the Trace Data #

Once you run the correct command, you'll get a trace.dat file. Now you can:

• Use KernelShark to open it directly for interactive visualization, filtering, and analysis of function call flows.
• Use trace-cmd report to generate a human-readable summary, or apply filters to focus on your module:

  trace-cmd report -F '*:mod:my_mod'
  

Extra Tips #

• If you want to include user-space process context (to see which user command triggered each function call), add the -U flag to the trace-cmd record command.
• If you're hitting buffer overflow (losing trace data), increase the buffer size with -b (e.g., -b 16384 for 16MB buffers per CPU).
• To limit tracing to specific CPUs, use -C followed by CPU numbers (e.g., -C 0,1 for CPUs 0 and 1).

内容的提问来源于stack exchange，提问作者Mo_