On Fri, Feb 6, 2026 at 2:05 AM Steven Rostedt <[email protected]> wrote: > > On Wed, 4 Feb 2026 22:52:11 +0800 > Donglin Peng <[email protected]> wrote: > > > > > I have trace-cmd reading BTF now (just haven't officially released it) > > > > and > > > > doing an extract and reading the trace.dat file is much faster than > > > > reading > > > > the trace file with arguments. I'll need to implement the enum logic > > > > too in > > > > libtraceevent. > > > > > > If you mean to do pretty printing of the trace in user space then +1 from > > > me. > > > > > > I don't like sorting enums either in resolve_btfid, pahole or kernel. > > > Sorted BTF by name was ok, since it doesn't change original semantics. > > > While sorting enums by value gets us to the grey zone where > > > the sequence of enum names in vmlinux.h becomes different than in dwarf. > > > > Thanks, I agreed. > > BTW, I just officially released trace-cmd v3.4 (where you can see whats > new in that release here[1]). > > The biggest change is that it saves the BTF file in the trace.dat file > and parses it on the report (it requires libtraceevent v1.9): > > ~# trace-cmd record -p function_graph -O funcgraph-args -g do_sys_openat2 > [..] > ~# trace-cmd report > trace-cmd-50935 [002] ...1. 3490.518138: funcgraph_entry: > | do_sys_openat2(dfd=4294967196, filename=0x557bb9e3ee10, > how=0xffff88815220fea8) { > trace-cmd-50935 [002] ...1. 3490.518141: funcgraph_entry: > | getname_flags(filename=0x557bb9e3ee10, flags=0) { > trace-cmd-50935 [002] ...1. 3490.518142: funcgraph_entry: > | getname_flags.part.0(filename=0x557bb9e3ee10, flags=0) { > trace-cmd-50935 [002] ...1. 3490.518143: funcgraph_entry: > | kmem_cache_alloc_noprof(s=0xffff888106c7e000, gfpflags=0xcc0) { > trace-cmd-50935 [002] ...1. 3490.518145: funcgraph_entry: > | stack_trace_save(store=0xffff88815220fac8, size=0x40, > skipnr=0x0) { > trace-cmd-50935 [002] ...1. 3490.518147: funcgraph_entry: > | arch_stack_walk(consume_entry=0xffffffff94d9dfe0, > cookie=0xffff88815220fa58, task=0xffff88812d4c3580, regs=0x0) { > trace-cmd-50935 [002] ...1. 3490.518148: funcgraph_entry: > | __unwind_start(state=0xffff88815220f988, > task=0xffff88812d4c3580, regs=0x0, first_frame=0xffff88815220fa28) { > trace-cmd-50935 [002] ...1. 3490.518149: funcgraph_entry: > 1.518 us | get_stack_info(stack=0xffff88815220f938, > task=0xffff88812d4c3580, info=0xffff88815220f988, > visit_mask=0xffff88815220f9a8); (ret=0x0) > trace-cmd-50935 [002] ...1. 3490.518152: funcgraph_entry: > | unwind_next_frame(state=0xffff88815220f988) { > trace-cmd-50935 [002] ...1. 3490.518153: funcgraph_entry: > 0.951 us | __rcu_read_lock(); (ret=0xffff88812d4c3580)
Thanks, I will implement this feature in libtraceevent. > > -- Steve > > > > [1] > https://git.kernel.org/pub/scm/utils/trace-cmd/trace-cmd.git/tag/?h=trace-cmd-v3.4
