forked from acmel/dwarves
-
Notifications
You must be signed in to change notification settings - Fork 1
/
changes-v1.18
117 lines (96 loc) · 4.33 KB
/
changes-v1.18
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
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 <[email protected]>