Hi, The v1.18 release of pahole and its friends is out, available at the usual places: Main git repo: git://git.kernel.org/pub/scm/devel/pahole/pahole.git Mirror git repo: https://github.com/acmel/dwarves.git tarball + gpg signature: https://fedorapeople.org/~acme/dwarves/dwarves-1.18.tar.xz https://fedorapeople.org/~acme/dwarves/dwarves-1.18.tar.bz2 https://fedorapeople.org/~acme/dwarves/dwarves-1.18.tar.sign Best Regards, v1.18: - Use type information to pretty print raw data from stdin, all documented in the man pages, further information in the csets. TLDRish: this almost completely deciphers a perf.data file: $ pahole ~/bin/perf --header=perf_file_header \ -C 'perf_file_attr(range=attrs),perf_event_header(range=data,sizeof,type,type_enum=perf_event_type+perf_user_event_type)' < perf.data What the above command line does: This will state that a 'struct perf_file_header' is available in BTF or DWARF in the ~/bin/perf file and that at the start of stdin it should be used to decode sizeof(struct perf_file_header) bytes, pretty printing it according to its members. Furthermore, that header can be referenced later in the command line, for instance that 'range=data' means that in the header, it expects a 'range' member in 'struct perf_file_header' to be used: $ pahole ~/bin/perf --header=perf_file_header < perf.data { .magic = 3622385352885552464, .size = 104, .attr_size = 136, .attrs = { .offset = 296, .size = 136, }, .data = { .offset = 432, .size = 14688, }, .event_types = { .offset = 0, .size = 0, }, .adds_features = { 376537084, 0, 0, 0 }, }, $ That 'range' field is expected to have 'offset' and 'size' fields, so that it can go on decoding a number of 'struct perf_event_header' entries. That 'sizeof' in turn expects that in 'struct perf_event_header' there is a 'size' field stating how long that particular record is, one can also use 'sizeof=some_other_member_name'. This supports variable sized records and then the 'type' field expects there is a 'struct perf_event_type' member named 'type' (again, type=something_else may be used. Finally, the value in the 'type' field is used to lookup an entry in the set formed by the two enumerations specified in the 'type_enum=' argument. If we look at these enums we'll see that its entries have names that can be, when lowercased, point to structs containing the layout for the variable sized record, which allows it to cast and produce the right pretty printed output. I.e. using the kernel BTF info we get: $ pahole perf_event_type enum perf_event_type { PERF_RECORD_MMAP = 1, PERF_RECORD_LOST = 2, PERF_RECORD_COMM = 3, PERF_RECORD_EXIT = 4, PERF_RECORD_THROTTLE = 5, PERF_RECORD_UNTHROTTLE = 6, PERF_RECORD_FORK = 7, PERF_RECORD_READ = 8, PERF_RECORD_SAMPLE = 9, PERF_RECORD_MMAP2 = 10, PERF_RECORD_AUX = 11, PERF_RECORD_ITRACE_START = 12, PERF_RECORD_LOST_SAMPLES = 13, PERF_RECORD_SWITCH = 14, PERF_RECORD_SWITCH_CPU_WIDE = 15, PERF_RECORD_NAMESPACES = 16, PERF_RECORD_KSYMBOL = 17, PERF_RECORD_BPF_EVENT = 18, PERF_RECORD_CGROUP = 19, PERF_RECORD_TEXT_POKE = 20, PERF_RECORD_MAX = 21, }; $ That is the same as in ~/bin/perf, and, if we get one of these and ask for that struct: $ pahole -C perf_record_mmap ~/bin/perf struct perf_record_mmap { struct perf_event_header header; /* 0 8 */ __u32 pid; /* 8 4 */ __u32 tid; /* 12 4 */ __u64 start; /* 16 8 */ __u64 len; /* 24 8 */ __u64 pgoff; /* 32 8 */ char filename[4096]; /* 40 4096 */ /* size: 4136, cachelines: 65, members: 7 */ /* last cacheline: 40 bytes */ }; $ Many other options were introduced to work with this, including --count, --skip, etc, look at the man page for details. - Store percpu variables in vmlinux BTF. This can be disabled when debugging kernel features being developed to use it. - pahole now should be segfault free when handling gdb test suit DWARF files, including ADA, FORTRAN, rust and dwp compressed files, the later being just flatly refused, that got left for v1.19. - Bail out on partial units for now, avoiding segfaults and providing warning to user, hopefully will be addressed in v1.19. Signed-off-by: Arnaldo Carvalho de Melo <acme@xxxxxxxxxx>
