perf tools: Display eBPF code in intel_pt trace
Jiri Olsa
reviewerv3 cover perf tools: Display eBPF code in intel_pt trace
hi,
this patchset adds dso support to read and display bpf code in intel_pt trace output. I had to change some of the kernel maps processing code, so hopefully I did not break too many things ;-)
It's now possible to see bpf code flow via:
# perf-with-kcore record pt -e intel_pt//ku -- sleep 1
# perf-with-kcore script pt --insn-trace --xed
...
sleep 36660 [016] 1057036.806464404: ffffffff811dfba5 trace_call_bpf+0x65 ([kernel.kallsyms]) nopl %eax, (%rax,%rax,1)
sleep 36660 [016] 1057036.806464404: ffffffff811dfbaa trace_call_bpf+0x6a ([kernel.kallsyms]) movq 0x30(%rbx), %rax
sleep 36660 [016] 1057036.806464404: ffffffff811dfbae trace_call_bpf+0x6e ([kernel.kallsyms]) leaq 0x38(%rbx), %rsi
sleep 36660 [016] 1057036.806464404: ffffffff811dfbb2 trace_call_bpf+0x72 ([kernel.kallsyms]) mov %r13, %rdi
sleep 36660 [016] 1057036.806464404: ffffffff811dfbb5 trace_call_bpf+0x75 ([kernel.kallsyms]) callq 0xffffffff81c00c30
sleep 36660 [016] 1057036.806464404: ffffffff81c00c30 __x86_indirect_thunk_rax+0x0 ([kernel.kallsyms]) callq 0xffffffff81c00c3c
sleep 36660 [016] 1057036.806464404: ffffffff81c00c3c __x86_indirect_thunk_rax+0xc ([kernel.kallsyms]) movq %rax, (%rsp)
sleep 36660 [016] 1057036.806464404: ffffffff81c00c40 __x86_indirect_thunk_rax+0x10 ([kernel.kallsyms]) retq
sleep 36660 [016] 1057036.806464725: ffffffffa05e89ef bpf_prog_da4fe6b3d2c29b25_trace_return+0x0 (bpf_prog_da4fe6b3d2c29b25_trace_return) pushq %rbp
sleep 36660 [016] 1057036.806464725: ffffffffa05e89f0 bpf_prog_da4fe6b3d2c29b25_trace_return+0x1 (bpf_prog_da4fe6b3d2c29b25_trace_return) mov %rsp, %rbp
sleep 36660 [016] 1057036.806464725: ffffffffa05e89f3 bpf_prog_da4fe6b3d2c29b25_trace_return+0x4 (bpf_prog_da4fe6b3d2c29b25_trace_return) sub $0x158, %rsp
sleep 36660 [016] 1057036.806464725: ffffffffa05e89fa bpf_prog_da4fe6b3d2c29b25_trace_return+0xb (bpf_prog_da4fe6b3d2c29b25_trace_return) sub $0x28, %rbp
sleep 36660 [016] 1057036.806464725: ffffffffa05e89fe bpf_prog_da4fe6b3d2c29b25_trace_return+0xf (bpf_prog_da4fe6b3d2c29b25_trace_return) movq %rbx, (%rbp)
sleep 36660 [016] 1057036.806464725: ffffffffa05e8a02 bpf_prog_da4fe6b3d2c29b25_trace_return+0x13 (bpf_prog_da4fe6b3d2c29b25_trace_return) movq %r13, 0x8(%rbp)
sleep 36660 [016] 1057036.806464725: ffffffffa05e8a06 bpf_prog_da4fe6b3d2c29b25_trace_return+0x17 (bpf_prog_da4fe6b3d2c29b25_trace_return) movq %r14, 0x10(%rbp)
sleep 36660 [016] 1057036.806464725: ffffffffa05e8a0a bpf_prog_da4fe6b3d2c29b25_trace_return+0x1b (bpf_prog_da4fe6b3d2c29b25_trace_return) movq %r15, 0x18(%rbp)
sleep 36660 [016] 1057036.806464725: ffffffffa05e8a0e bpf_prog_da4fe6b3d2c29b25_trace_return+0x1f (bpf_prog_da4fe6b3d2c29b25_trace_return) xor %eax, %eax
sleep 36660 [016] 1057036.806464725: ffffffffa05e8a10 bpf_prog_da4fe6b3d2c29b25_trace_return+0x21 (bpf_prog_da4fe6b3d2c29b25_trace_return) movq %rax, 0x20(%rbp)
sleep 36660 [016] 1057036.806464725: ffffffffa05e8a14 bpf_prog_da4fe6b3d2c29b25_trace_return+0x25 (bpf_prog_da4fe6b3d2c29b25_trace_return) mov %rdi, %rbx
sleep 36660 [016] 1057036.806464725: ffffffffa05e8a17 bpf_prog_da4fe6b3d2c29b25_trace_return+0x28 (bpf_prog_da4fe6b3d2c29b25_trace_return) callq 0xffffffff811fed50
sleep 36660 [016] 1057036.806464725: ffffffff811fed50 bpf_get_current_pid_tgid+0x0 ([kernel.kallsyms]) nopl %eax, (%rax,%rax,1)
sleep 36660 [016] 1057036.806464725: ffffffff811fed55 bpf_get_current_pid_tgid+0x5 ([kernel.kallsyms]) movq %gs:0x15c00, %rdx
sleep 36660 [016] 1057036.806464725: ffffffff811fed5e bpf_get_current_pid_tgid+0xe ([kernel.kallsyms]) test %rdx, %rdx
sleep 36660 [016] 1057036.806464725: ffffffff811fed61 bpf_get_current_pid_tgid+0x11 ([kernel.kallsyms]) jz 0xffffffff811fed79
sleep 36660 [016] 1057036.806464725: ffffffff811fed63 bpf_get_current_pid_tgid+0x13 ([kernel.kallsyms]) movsxdl 0x494(%rdx), %rax
sleep 36660 [016] 1057036.806464725: ffffffff811fed6a bpf_get_current_pid_tgid+0x1a ([kernel.kallsyms]) movsxdl 0x490(%rdx), %rdx
sleep 36660 [016] 1057036.806464725: ffffffff811fed71 bpf_get_current_pid_tgid+0x21 ([kernel.kallsyms]) shl $0x20, %rax
sleep 36660 [016] 1057036.806464725: ffffffff811fed75 bpf_get_current_pid_tgid+0x25 ([kernel.kallsyms]) or %rdx, %rax
sleep 36660 [016] 1057036.806464725: ffffffff811fed78 bpf_get_current_pid_tgid+0x28 ([kernel.kallsyms]) retq
sleep 36660 [016] 1057036.806464725: ffffffffa05e8a1c bpf_prog_da4fe6b3d2c29b25_trace_return+0x2d (bpf_prog_da4fe6b3d2c29b25_trace_return) movq %rax, -0x8(%rbp)
sleep 36660 [016] 1057036.806464725: ffffffffa05e8a20 bpf_prog_da4fe6b3d2c29b25_trace_return+0x31 (bpf_prog_da4fe6b3d2c29b25_trace_return) xor %edi, %edi
sleep 36660 [016] 1057036.806464725: ffffffffa05e8a22 bpf_prog_da4fe6b3d2c29b25_trace_return+0x33 (bpf_prog_da4fe6b3d2c29b25_trace_return) movq %rdi, -0x10(%rbp)
sleep 36660 [016] 1057036.806464725: ffffffffa05e8a26 bpf_prog_da4fe6b3d2c29b25_trace_return+0x37 (bpf_prog_da4fe6b3d2c29b25_trace_return) movq %rdi, -0x18(%rbp) # perf-core/perf-with-kcore script pt --call-trace
...
sleep 36660 [016] 1057036.806464404: ([kernel.kallsyms] ) kretprobe_perf_func
sleep 36660 [016] 1057036.806464404: ([kernel.kallsyms] ) trace_call_bpf
sleep 36660 [016] 1057036.806464404: ([kernel.kallsyms] ) __x86_indirect_thunk_rax
sleep 36660 [016] 1057036.806464404: ([kernel.kallsyms] ) __x86_indirect_thunk_rax
sleep 36660 [016] 1057036.806464725: (bpf_prog_da4fe6b3d2c29b25_trace_return ) bpf_get_current_pid_tgid
sleep 36660 [016] 1057036.806464725: (bpf_prog_da4fe6b3d2c29b25_trace_return ) bpf_ktime_get_ns
sleep 36660 [016] 1057036.806464725: ([kernel.kallsyms] ) __x86_indirect_thunk_rax
sleep 36660 [016] 1057036.806464725: ([kernel.kallsyms] ) __x86_indirect_thunk_rax
sleep 36660 [016] 1057036.806465045: (bpf_prog_da4fe6b3d2c29b25_trace_return ) __htab_map_lookup_elem
sleep 36660 [016] 1057036.806465366: ([kernel.kallsyms] ) memcmp
sleep 36660 [016] 1057036.806465687: (bpf_prog_da4fe6b3d2c29b25_trace_return ) bpf_probe_read
sleep 36660 [016] 1057036.806465687: ([kernel.kallsyms] ) probe_kernel_read
sleep 36660 [016] 1057036.806465687: ([kernel.kallsyms] ) __check_object_size
sleep 36660 [016] 1057036.806465687: ([kernel.kallsyms] ) check_stack_object
sleep 36660 [016] 1057036.806465687: ([kernel.kallsyms] ) copy_user_enhanced_fast_string
sleep 36660 [016] 1057036.806465687: (bpf_prog_da4fe6b3d2c29b25_trace_return ) bpf_probe_read
sleep 36660 [016] 1057036.806465687: ([kernel.kallsyms] ) probe_kernel_read
sleep 36660 [016] 1057036.806465687: ([kernel.kallsyms] ) __check_object_size
sleep 36660 [016] 1057036.806465687: ([kernel.kallsyms] ) check_stack_object
sleep 36660 [016] 1057036.806465687: ([kernel.kallsyms] ) copy_user_enhanced_fast_string
sleep 36660 [016] 1057036.806466008: (bpf_prog_da4fe6b3d2c29b25_trace_return ) bpf_get_current_uid_gid
sleep 36660 [016] 1057036.806466008: ([kernel.kallsyms] ) from_kgid
sleep 36660 [016] 1057036.806466008: ([kernel.kallsyms] ) from_kuid
sleep 36660 [016] 1057036.806466008: (bpf_prog_da4fe6b3d2c29b25_trace_return ) bpf_perf_event_output
sleep 36660 [016] 1057036.806466328: ([kernel.kallsyms] ) perf_event_output
sleep 36660 [016] 1057036.806466328: ([kernel.kallsyms] ) perf_prepare_sample
sleep 36660 [016] 1057036.806466328: ([kernel.kallsyms] ) perf_misc_flags
sleep 36660 [016] 1057036.806466328: ([kernel.kallsyms] ) __x86_indirect_thunk_rax
sleep 36660 [016] 1057036.806466328: ([kernel.kallsyms] ) __x86_indirect_thunk_raxv3 changes:
- fix the padding code in patch 7 (Song Liu)
- rebased on current Arnaldo's perf/core with merged perf/urgent
v2 changes:
- fix missing pthread_mutex_unlock [Stanislav Fomichev]
- removed eBPF dso reusing [Adrian Hunter]
- merge eBPF and kcore maps [Adrian Hunter]
- few patches already applied
- added some perf script helper options
- patches are rebased on top of Arnaldo's perf/core with perf/urgent merged in
It's also available in here:
git://git.kernel.org/pub/scm/linux/kernel/git/jolsa/perf.git
perf/fixes
thanks,
jirka
---
Jiri Olsa (12):
perf tools: Separate generic code in dso__data_file_size perf tools: Separate generic code in dso_cache__read perf tools: Simplify dso_cache__read function
perf tools: Add bpf dso read and size hooks
perf tools: Read also the end of the kernel
perf tools: Keep zero in pgoff bpf map
perf script: Pad dso name for --call-trace
perf tools: Preserve eBPF maps when loading kcore perf tests: Add map_groups__merge_in test
perf script: Add --show-bpf-events to show eBPF related events perf script: Remove superfluous bpf event titles perf script: Add --show-all-events option
tools/include/linux/kernel.h | 1 + tools/lib/vsprintf.c | 19 +++++++++++++++++++ tools/perf/Documentation/perf-script.txt | 6 ++++++ tools/perf/builtin-script.c | 56 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++ tools/perf/tests/Build | 1 + tools/perf/tests/builtin-test.c | 4 ++++ tools/perf/tests/map_groups.c | 120 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ tools/perf/tests/tests.h | 1 + tools/perf/util/dso.c | 125 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++------------------------------------ tools/perf/util/event.c | 4 ++-- tools/perf/util/machine.c | 31 ++++++++++++++++++++----------- tools/perf/util/map.c | 6 ++++++ tools/perf/util/map_groups.h | 2 ++ tools/perf/util/symbol.c | 97 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++---- tools/perf/util/symbol_conf.h | 1 + 15 files changed, 421 insertions(+), 53 deletions(-) create mode 100644 tools/perf/tests/map_groups.c
Jiri Olsa
reviewerPATCH v3 1/12 perf tools: Separate generic code in dso__data_file_size
Moving file specific code in dso__data_file_size function into separate file_size function. I'll add bpf specific code in following patches.
--- tools/perf/util/dso.c | 19 ++++++++++++------- 1 file changed, 12 insertions(+), 7 deletions(-)
tools/perf/util/dso.c +12 -7
@@ -898,18 +898,12 @@ static ssize_t cached_read(struct dso *dso, struct machine *machine,return r; } -int dso__data_file_size (struct dso *dso,struct machine *machine) +static int file_size (struct dso *dso,struct machine *machine) {int ret =0 ;struct stat st;char sbuf[STRERR_BUFSIZE ]; -if (dso->data.file_size) -return 0 ; - -if (dso->data.status ==DSO_DATA_STATUS_ERROR ) -return -1 ; -pthread_mutex_lock (&dso__data_open_lock);/*
@@ -938,6 +932,17 @@ int dso__data_file_size(struct dso *dso, struct machine *machine)return ret; } +int dso__data_file_size (struct dso *dso,struct machine *machine) +{ +if (dso->data.file_size) +return 0 ; + +if (dso->data.status ==DSO_DATA_STATUS_ERROR ) +return -1 ; + +return file_size (dso, machine); +} +/** * dso__data_size - Return dso data size * @dso: dso object
Signature · 1 line
2.20.1
Re: [PATCH 01/12] perf tools: Separate generic code in dso__data_file_size
Em Wed, May 08, 2019 at 03:19:59PM +0200, Jiri Olsa escreveu:
Quoted 3 lines
Moving file specific code in
dso__data_file_sizefunction into separatefile_sizefunction. I'll add bpf specific code in following patches.
I'm applying this patch, as it just moves things around, no logic change, but can you please clarify a question I have after looking at this patch?
Quoted 34 lines
Signed-off-by Jiri Olsa <[email protected]>--- tools/perf/util/dso.c | 19 ++++++++++++------- 1 file changed, 12 insertions(+), 7 deletions(-)tools/perf/util/dso.c +1
-7@@ -898,18 +898,12 @@ static ssize_t cached_read(struct dso *dso, struct machine *machine,return r; } -int dso__data_file_size (struct dso *dso,struct machine *machine) +static int file_size (struct dso *dso,struct machine *machine) {int ret =0 ;struct stat st;char sbuf[STRERR_BUFSIZE ]; -if (dso->data.file_size) -return 0 ; - -if (dso->data.status ==DSO_DATA_STATUS_ERROR ) -return -1 ; -pthread_mutex_lock (&dso__data_open_lock);/* @@ -938,6 +932,17 @@ int dso__data_file_size(struct dso *dso, struct machine *machine)return ret; }
tools/perf/util/dso.c int dso__data_file_size(struct dso *dso, struct machine *machine) · line 944
Quoted 10 lines
tools/perf/util/dso.c +10
-0+int dso__data_file_size (struct dso *dso,struct machine *machine) +{ +if (dso->data.file_size) +return 0 ; + +if (dso->data.status ==DSO_DATA_STATUS_ERROR ) +return -1 ; + +return file_size (dso, machine); +}
So the name of the function suggests we want to know the "data_file_size" of a dso, then the logic in it returns _zero_ if a member named "dso->data.file_size" is _not_ zero, can you please clarify?
I was expecting something like:
if (dso->data.file_size) return dso->data.file_size;
I.e. if we had already read it, return the cached value, otherwise go and call some other function to get that info somehow.
- Arnaldo
Quoted 6 lines
tools/perf/util/dso.c +1
-0+/** * dso__data_size - Return dso data size * @dso: dso object Signature · 1 line
2.20.1
Signature · 1 line
- Arnaldo
Re: [PATCH 01/12] perf tools: Separate generic code in dso__data_file_size
Quoted 60 lines · Arnaldo Carvalho de Melo
Em Wed, May 08, 2019 at 03:19:59PM +0200, Jiri Olsa escreveu:
Quoted 3 lines
Moving file specific code in
dso__data_file_sizefunction into separatefile_sizefunction. I'll add bpf specific code in following patches.I'm applying this patch, as it just moves things around, no logic change, but can you please clarify a question I have after looking at this patch?
Quoted 34 lines
Signed-off-by Jiri Olsa <[email protected]>--- tools/perf/util/dso.c | 19 ++++++++++++------- 1 file changed, 12 insertions(+), 7 deletions(-)tools/perf/util/dso.c +1
-7@@ -898,18 +898,12 @@ static ssize_t cached_read(struct dso *dso, struct machine *machine,return r; } -int dso__data_file_size (struct dso *dso,struct machine *machine) +static int file_size (struct dso *dso,struct machine *machine) {int ret =0 ;struct stat st;char sbuf[STRERR_BUFSIZE ]; -if (dso->data.file_size) -return 0 ; - -if (dso->data.status ==DSO_DATA_STATUS_ERROR ) -return -1 ; -pthread_mutex_lock (&dso__data_open_lock);/* @@ -938,6 +932,17 @@ int dso__data_file_size(struct dso *dso, struct machine *machine)return ret; }tools/perf/util/dso.c int dso__data_file_size(struct dso *dso, struct machine *machine) · line 944
Quoted 10 lines
tools/perf/util/dso.c +10
-0+int dso__data_file_size (struct dso *dso,struct machine *machine) +{ +if (dso->data.file_size) +return 0 ; + +if (dso->data.status ==DSO_DATA_STATUS_ERROR ) +return -1 ; + +return file_size (dso, machine); +}So the name of the function suggests we want to know the "
data_file_size" of a dso, then the logic in it returns _zero_ if a member named "dso->data.file_size" is _not_ zero, can you please clarify?
Quoted 7 lines
I was expecting something like:
if (dso->data.file_size) return dso->data.file_size;I.e. if we had already read it, return the cached value, otherwise go and call some other function to get that info somehow.
we keep the data size in dso->data.file_size, the function just updates it
the return code is the error code.. not sure, why its like that, but it is ;-)
maybe we wanted separate size and error code, because the size needs to be u64 and we use int everywhere.. less casting
jirka
Namhyung Kim
maintainerRe: [PATCH 01/12] perf tools: Separate generic code in dso__data_file_size
Hi Jirka,
Quoted 72 lines · Jiri Olsa
Quoted 60 lines · Arnaldo Carvalho de Melo
Em Wed, May 08, 2019 at 03:19:59PM +0200, Jiri Olsa escreveu:
Quoted 3 lines
Moving file specific code in
dso__data_file_sizefunction into separatefile_sizefunction. I'll add bpf specific code in following patches.I'm applying this patch, as it just moves things around, no logic change, but can you please clarify a question I have after looking at this patch?
Quoted 34 lines
Signed-off-by Jiri Olsa <[email protected]>--- tools/perf/util/dso.c | 19 ++++++++++++------- 1 file changed, 12 insertions(+), 7 deletions(-)tools/perf/util/dso.c +1
-7@@ -898,18 +898,12 @@ static ssize_t cached_read(struct dso *dso, struct machine *machine,return r; } -int dso__data_file_size (struct dso *dso,struct machine *machine) +static int file_size (struct dso *dso,struct machine *machine) {int ret =0 ;struct stat st;char sbuf[STRERR_BUFSIZE ]; -if (dso->data.file_size) -return 0 ; - -if (dso->data.status ==DSO_DATA_STATUS_ERROR ) -return -1 ; -pthread_mutex_lock (&dso__data_open_lock);/* @@ -938,6 +932,17 @@ int dso__data_file_size(struct dso *dso, struct machine *machine)return ret; }tools/perf/util/dso.c int dso__data_file_size(struct dso *dso, struct machine *machine) · line 944
Quoted 10 lines
tools/perf/util/dso.c +10
-0+int dso__data_file_size (struct dso *dso,struct machine *machine) +{ +if (dso->data.file_size) +return 0 ; + +if (dso->data.status ==DSO_DATA_STATUS_ERROR ) +return -1 ; + +return file_size (dso, machine); +}So the name of the function suggests we want to know the "
data_file_size" of a dso, then the logic in it returns _zero_ if a member named "dso->data.file_size" is _not_ zero, can you please clarify?Quoted 7 lines
I was expecting something like:
if (dso->data.file_size) return dso->data.file_size;I.e. if we had already read it, return the cached value, otherwise go and call some other function to get that info somehow.
we keep the data size in
dso->data.file_size, the function just updates it
Quoted 6 lines
the return code is the error code.. not sure, why its like that, but it is ;-)
maybe we wanted separate size and error code, because the size needs to be u64 and we use int everywhere.. less casting
Maybe we can rename it to dso__update_file_size().
Thanks,
Namhyung
Re: [PATCH 01/12] perf tools: Separate generic code in dso__data_file_size
Quoted 75 lines · Namhyung Kim
Hi Jirka,
Quoted 72 lines · Jiri Olsa
Quoted 60 lines · Arnaldo Carvalho de Melo
Em Wed, May 08, 2019 at 03:19:59PM +0200, Jiri Olsa escreveu:
Quoted 3 lines
Moving file specific code in
dso__data_file_sizefunction into separatefile_sizefunction. I'll add bpf specific code in following patches.I'm applying this patch, as it just moves things around, no logic change, but can you please clarify a question I have after looking at this patch?
Quoted 34 lines
Signed-off-by Jiri Olsa <[email protected]>--- tools/perf/util/dso.c | 19 ++++++++++++------- 1 file changed, 12 insertions(+), 7 deletions(-)tools/perf/util/dso.c +1
-7@@ -898,18 +898,12 @@ static ssize_t cached_read(struct dso *dso, struct machine *machine,return r; } -int dso__data_file_size (struct dso *dso,struct machine *machine) +static int file_size (struct dso *dso,struct machine *machine) {int ret =0 ;struct stat st;char sbuf[STRERR_BUFSIZE ]; -if (dso->data.file_size) -return 0 ; - -if (dso->data.status ==DSO_DATA_STATUS_ERROR ) -return -1 ; -pthread_mutex_lock (&dso__data_open_lock);/* @@ -938,6 +932,17 @@ int dso__data_file_size(struct dso *dso, struct machine *machine)return ret; }tools/perf/util/dso.c int dso__data_file_size(struct dso *dso, struct machine *machine) · line 944
Quoted 10 lines
tools/perf/util/dso.c +10
-0+int dso__data_file_size (struct dso *dso,struct machine *machine) +{ +if (dso->data.file_size) +return 0 ; + +if (dso->data.status ==DSO_DATA_STATUS_ERROR ) +return -1 ; + +return file_size (dso, machine); +}So the name of the function suggests we want to know the "
data_file_size" of a dso, then the logic in it returns _zero_ if a member named "dso->data.file_size" is _not_ zero, can you please clarify?Quoted 7 lines
I was expecting something like:
if (dso->data.file_size) return dso->data.file_size;I.e. if we had already read it, return the cached value, otherwise go and call some other function to get that info somehow.
we keep the data size in
dso->data.file_size, the function just updates it
Quoted 8 lines
Quoted 6 lines
the return code is the error code.. not sure, why its like that, but it is ;-)
maybe we wanted separate size and error code, because the size needs to be u64 and we use int everywhere.. less casting
Maybe we can rename it to
dso__update_file_size().
sounds good, I'll queue it
thanks,
jirka
tip-bot for Jiri Olsa
merge bot[tip:perf/core] perf dso: Separate generic code in dso__data_file_size()
In reply to Jiri Olsaperf dso: Separate generic code in dso__data_file_size()
Commit-ID: 5523769ee15f27a1bc2009346736b22cb907bff8 Gitweb: https://git.kernel.org/tip/5523769ee15f27a1bc2009346736b22cb907bff8 Author: Jiri Olsa <[email protected]> AuthorDate: Wed, 8 May 2019 15:19:59 +0200 Committer: Arnaldo Carvalho de Melo <[email protected]> CommitDate: Tue, 28 May 2019 18:37:43 -0300
perf dso: Separate generic code in dso__data_file_size()
Moving file specific code in dso__data_file_size function into separate file_size function. I'll add bpf specific code in following patches.
--- tools/perf/util/dso.c | 19 ++++++++++++------- 1 file changed, 12 insertions(+), 7 deletions(-)
tools/perf/util/dso.c +12 -7
@@ -898,18 +898,12 @@ static ssize_t cached_read(struct dso *dso, struct machine *machine,return r; } -int dso__data_file_size (struct dso *dso,struct machine *machine) +static int file_size (struct dso *dso,struct machine *machine) {int ret =0 ;struct stat st;char sbuf[STRERR_BUFSIZE ]; -if (dso->data.file_size) -return 0 ; - -if (dso->data.status ==DSO_DATA_STATUS_ERROR ) -return -1 ; -pthread_mutex_lock (&dso__data_open_lock);/*
@@ -938,6 +932,17 @@ out:return ret; } +int dso__data_file_size (struct dso *dso,struct machine *machine) +{ +if (dso->data.file_size) +return 0 ; + +if (dso->data.status ==DSO_DATA_STATUS_ERROR ) +return -1 ; + +return file_size (dso, machine); +} +/** * dso__data_size - Return dso data size * @dso: dso object
Jiri Olsa
reviewerPATCH v3 2/12 perf tools: Separate generic code in dso_cache__read
In reply to Jiri OlsaMoving file specific code in dso_cache__read function into separate file_read function. I'll add bpf specific code in following patches.
--- tools/perf/util/dso.c | 48 ++++++++++++++++++++++++------------------- 1 file changed, 27 insertions(+), 21 deletions(-)
tools/perf/util/dso.c +27 -21
@@ -794,6 +794,31 @@ dso_cache__memcpy(struct dso_cache *cache, u64 offset,return cache_size; } +static ssize_t file_read (struct dso *dso,struct machine *machine, +u64 offset,char *data) +{ +ssize_t ret; + +pthread_mutex_lock (&dso__data_open_lock); + +/* +* dso->data.fd might be closed if other thread opened another +* file (dso) due to open file limit (RLIMIT_NOFILE). +*/ +try_to_open_dso (dso, machine); + +if (dso->data.fd <0 ) { + dso->data.status =DSO_DATA_STATUS_ERROR ; + ret = -errno; + goto out; + } + + ret =pread (dso->data.fd, data,DSO__DATA_CACHE_SIZE , offset); +out: +pthread_mutex_unlock (&dso__data_open_lock); +return ret; +} +static ssize_t dso_cache__read (struct dso *dso,struct machine *machine,u64 offset,u8 *data,ssize_t size)
@@ -803,37 +828,18 @@ dso_cache__read(struct dso *dso, struct machine *machine,ssize_t ret;do { -u64 cache_offset; +u64 cache_offset = offset &DSO__DATA_CACHE_MASK ; cache =zalloc (sizeof (*cache) +DSO__DATA_CACHE_SIZE );if (!cache)return -ENOMEM ; -pthread_mutex_lock (&dso__data_open_lock); - -/* -* dso->data.fd might be closed if other thread opened another -* file (dso) due to open file limit (RLIMIT_NOFILE). -*/ -try_to_open_dso (dso, machine); - -if (dso->data.fd <0 ) { - ret = -errno; - dso->data.status =DSO_DATA_STATUS_ERROR ; -break ; - } - - cache_offset = offset &DSO__DATA_CACHE_MASK ; - - ret =pread (dso->data.fd, cache->data,DSO__DATA_CACHE_SIZE , cache_offset); -if (ret <=0 ) -break ; + ret =file_read (dso, machine, cache_offset, cache->data); cache->offset = cache_offset; cache->size = ret; }while (0 ); -pthread_mutex_unlock (&dso__data_open_lock);if (ret >0 ) { old =dso_cache__insert (dso, cache);
Signature · 1 line
2.20.1
tip-bot for Jiri Olsa
merge bot[tip:perf/core] perf dso: Separate generic code in dso_cache__read
perf dso: Separate generic code in dso_cache__read
Commit-ID: ea5db1bd5a04b865bc86bb8e3267c27939dfb5ee Gitweb: https://git.kernel.org/tip/ea5db1bd5a04b865bc86bb8e3267c27939dfb5ee Author: Jiri Olsa <[email protected]> AuthorDate: Wed, 8 May 2019 15:20:00 +0200 Committer: Arnaldo Carvalho de Melo <[email protected]> CommitDate: Tue, 28 May 2019 18:37:44 -0300
perf dso: Separate generic code in dso_cache__read
Move the file specific code in the dso_cache__read function to a separate file_read function. I'll add BPF specific code in the following patches.
--- tools/perf/util/dso.c | 48 +++++++++++++++++++++++++++--------------------- 1 file changed, 27 insertions(+), 21 deletions(-)
tools/perf/util/dso.c +27 -21
@@ -794,6 +794,31 @@ dso_cache__memcpy(struct dso_cache *cache, u64 offset,return cache_size; } +static ssize_t file_read (struct dso *dso,struct machine *machine, +u64 offset,char *data) +{ +ssize_t ret; + +pthread_mutex_lock (&dso__data_open_lock); + +/* +* dso->data.fd might be closed if other thread opened another +* file (dso) due to open file limit (RLIMIT_NOFILE). +*/ +try_to_open_dso (dso, machine); + +if (dso->data.fd <0 ) { + dso->data.status =DSO_DATA_STATUS_ERROR ; + ret = -errno; + goto out; + } + + ret =pread (dso->data.fd, data,DSO__DATA_CACHE_SIZE , offset); +out: +pthread_mutex_unlock (&dso__data_open_lock); +return ret; +} +static ssize_t dso_cache__read (struct dso *dso,struct machine *machine,u64 offset,u8 *data,ssize_t size)
@@ -803,37 +828,18 @@ dso_cache__read(struct dso *dso, struct machine *machine,ssize_t ret;do { -u64 cache_offset; +u64 cache_offset = offset &DSO__DATA_CACHE_MASK ; cache =zalloc (sizeof (*cache) +DSO__DATA_CACHE_SIZE );if (!cache)return -ENOMEM ; -pthread_mutex_lock (&dso__data_open_lock); - -/* -* dso->data.fd might be closed if other thread opened another -* file (dso) due to open file limit (RLIMIT_NOFILE). -*/ -try_to_open_dso (dso, machine); - -if (dso->data.fd <0 ) { - ret = -errno; - dso->data.status =DSO_DATA_STATUS_ERROR ; -break ; - } - - cache_offset = offset &DSO__DATA_CACHE_MASK ; - - ret =pread (dso->data.fd, cache->data,DSO__DATA_CACHE_SIZE , cache_offset); -if (ret <=0 ) -break ; + ret =file_read (dso, machine, cache_offset, cache->data); cache->offset = cache_offset; cache->size = ret; }while (0 ); -pthread_mutex_unlock (&dso__data_open_lock);if (ret >0 ) { old =dso_cache__insert (dso, cache);
Jiri Olsa
reviewerPATCH v3 3/12 perf tools: Simplify dso_cache__read function
In reply to Jiri OlsaThere's no need for the while loop now, also we can connect two (ret > 0) condition legs together.
--- tools/perf/util/dso.c | 17 ++++++----------- 1 file changed, 6 insertions(+), 11 deletions(-)
tools/perf/util/dso.c +6 -11
@@ -823,25 +823,20 @@ static ssize_t dso_cache__read(struct dso *dso, struct machine *machine, u64 offset, u8 *data, ssize_t size) { + u64 cache_offset = offset & DSO__DATA_CACHE_MASK;struct dso_cache *cache;struct dso_cache *old;ssize_t ret; -do { -u64 cache_offset = offset &DSO__DATA_CACHE_MASK ; - - cache =zalloc (sizeof (*cache) +DSO__DATA_CACHE_SIZE ); -if (!cache) -return -ENOMEM ; - - ret =file_read (dso, machine, cache_offset, cache->data); + cache =zalloc (sizeof (*cache) +DSO__DATA_CACHE_SIZE ); +if (!cache) +return -ENOMEM ; + ret =file_read (dso, machine, cache_offset, cache->data); +if (ret >0 ) { cache->offset = cache_offset; cache->size = ret; - }while (0 ); - -if (ret >0 ) { old =dso_cache__insert (dso, cache);if (old) {/* we lose the race */
Signature · 1 line
2.20.1
tip-bot for Jiri Olsa
merge bot[tip:perf/core] perf dso: Simplify dso_cache__read function
perf dso: Simplify dso_cache__read function
Commit-ID: cacddfe7b0804752528e8100461266ec33dc6b64 Gitweb: https://git.kernel.org/tip/cacddfe7b0804752528e8100461266ec33dc6b64 Author: Jiri Olsa <[email protected]> AuthorDate: Wed, 8 May 2019 15:20:01 +0200 Committer: Arnaldo Carvalho de Melo <[email protected]> CommitDate: Tue, 28 May 2019 18:37:44 -0300
perf dso: Simplify dso_cache__read function
There's no need for the while loop now, also we can connect two (ret >
0) condition legs together.
--- tools/perf/util/dso.c | 17 ++++++----------- 1 file changed, 6 insertions(+), 11 deletions(-)
tools/perf/util/dso.c +6 -11
@@ -823,25 +823,20 @@ static ssize_t dso_cache__read(struct dso *dso, struct machine *machine, u64 offset, u8 *data, ssize_t size) { + u64 cache_offset = offset & DSO__DATA_CACHE_MASK;struct dso_cache *cache;struct dso_cache *old;ssize_t ret; -do { -u64 cache_offset = offset &DSO__DATA_CACHE_MASK ; - - cache =zalloc (sizeof (*cache) +DSO__DATA_CACHE_SIZE ); -if (!cache) -return -ENOMEM ; - - ret =file_read (dso, machine, cache_offset, cache->data); + cache =zalloc (sizeof (*cache) +DSO__DATA_CACHE_SIZE ); +if (!cache) +return -ENOMEM ; + ret =file_read (dso, machine, cache_offset, cache->data); +if (ret >0 ) { cache->offset = cache_offset; cache->size = ret; - }while (0 ); - -if (ret >0 ) { old =dso_cache__insert (dso, cache);if (old) {/* we lose the race */
Jiri Olsa
reviewerPATCH v3 4/12 perf tools: Add bpf dso read and size hooks
In reply to Jiri OlsaAdding bpf related code into dso reading paths to return size (bpf_size) and read the bpf code (bpf_read).
--- tools/perf/util/dso.c | 49 ++++++++++++++++++++++++++++++++++++++++++- 1 file changed, 48 insertions(+), 1 deletion(-)
tools/perf/util/dso.c +48 -1
@@ -9,6 +9,8 @@#include <errno.h> #include <fcntl.h> #include <libgen.h> +#include <bpf/libbpf.h> +#include "bpf-event.h" #include "compress.h" #include "namespaces.h" #include "path.h"
@@ -706,6 +708,44 @@ bool dso__data_status_seen(struct dso *dso, enum dso_data_status_seen by)return false; } +static ssize_t bpf_read (struct dso *dso,u64 offset,char *data) +{ +struct bpf_prog_info_node *node; +ssize_t size =DSO__DATA_CACHE_SIZE ; +u64 len; +u8 *buf; + + node =perf_env__find_bpf_prog_info (dso->bpf_prog.env, dso->bpf_prog.id); +if (!node || !node->info_linear) { + dso->data.status =DSO_DATA_STATUS_ERROR ; +return -1 ; + } + + len = node->info_linear->info.jited_prog_len; + buf = (u8 *) node->info_linear->info.jited_prog_insns; + +if (offset >= len) +return -1 ; + + size = (ssize_t )min (len - offset, (u64 ) size); +memcpy (data, buf + offset, size); +return size; +} + +static int bpf_size (struct dso *dso) +{ +struct bpf_prog_info_node *node; + + node =perf_env__find_bpf_prog_info (dso->bpf_prog.env, dso->bpf_prog.id); +if (!node || !node->info_linear) { + dso->data.status =DSO_DATA_STATUS_ERROR ; +return -1 ; + } + + dso->data.file_size = node->info_linear->info.jited_prog_len; +return 0 ; +} +static void dso_cache__free (struct dso *dso) {
@@ -832,7 +872,11 @@ dso_cache__read(struct dso *dso, struct machine *machine,if (!cache)return -ENOMEM ; - ret =file_read (dso, machine, cache_offset, cache->data); +if (dso->binary_type ==DSO_BINARY_TYPE__BPF_PROG_INFO ) + ret =bpf_read (dso, cache_offset, cache->data); +else + ret =file_read (dso, machine, cache_offset, cache->data); +if (ret >0 ) { cache->offset = cache_offset; cache->size = ret;
@@ -941,6 +985,9 @@ int dso__data_file_size(struct dso *dso, struct machine *machine)if (dso->data.status ==DSO_DATA_STATUS_ERROR )return -1 ; +if (dso->binary_type ==DSO_BINARY_TYPE__BPF_PROG_INFO ) +return bpf_size (dso); +return file_size (dso, machine); }
Signature · 1 line
2.20.1
tip-bot for Jiri Olsa
merge bot[tip:perf/core] perf dso: Add BPF DSO read and size hooks
perf dso: Add BPF DSO read and size hooks
Commit-ID: 6c398d723a6a6d27485e701ae21e50304ec95595 Gitweb: https://git.kernel.org/tip/6c398d723a6a6d27485e701ae21e50304ec95595 Author: Jiri Olsa <[email protected]> AuthorDate: Wed, 8 May 2019 15:20:02 +0200 Committer: Arnaldo Carvalho de Melo <[email protected]> CommitDate: Tue, 28 May 2019 18:37:44 -0300
perf dso: Add BPF DSO read and size hooks
Add BPF related code into DSO reading paths to return size (bpf_size) and read the BPF code (bpf_read).
--- tools/perf/util/dso.c | 49 ++++++++++++++++++++++++++++++++++++++++++++++++- 1 file changed, 48 insertions(+), 1 deletion(-)
tools/perf/util/dso.c +48 -1
@@ -9,6 +9,8 @@#include <errno.h> #include <fcntl.h> #include <libgen.h> +#include <bpf/libbpf.h> +#include "bpf-event.h" #include "compress.h" #include "namespaces.h" #include "path.h"
@@ -706,6 +708,44 @@ bool dso__data_status_seen(struct dso *dso, enum dso_data_status_seen by)return false; } +static ssize_t bpf_read (struct dso *dso,u64 offset,char *data) +{ +struct bpf_prog_info_node *node; +ssize_t size =DSO__DATA_CACHE_SIZE ; +u64 len; +u8 *buf; + + node =perf_env__find_bpf_prog_info (dso->bpf_prog.env, dso->bpf_prog.id); +if (!node || !node->info_linear) { + dso->data.status =DSO_DATA_STATUS_ERROR ; +return -1 ; + } + + len = node->info_linear->info.jited_prog_len; + buf = (u8 *)(uintptr_t )node->info_linear->info.jited_prog_insns; + +if (offset >= len) +return -1 ; + + size = (ssize_t )min (len - offset, (u64 )size); +memcpy (data, buf + offset, size); +return size; +} + +static int bpf_size (struct dso *dso) +{ +struct bpf_prog_info_node *node; + + node =perf_env__find_bpf_prog_info (dso->bpf_prog.env, dso->bpf_prog.id); +if (!node || !node->info_linear) { + dso->data.status =DSO_DATA_STATUS_ERROR ; +return -1 ; + } + + dso->data.file_size = node->info_linear->info.jited_prog_len; +return 0 ; +} +static void dso_cache__free (struct dso *dso) {
@@ -832,7 +872,11 @@ dso_cache__read(struct dso *dso, struct machine *machine,if (!cache)return -ENOMEM ; - ret =file_read (dso, machine, cache_offset, cache->data); +if (dso->binary_type ==DSO_BINARY_TYPE__BPF_PROG_INFO ) + ret =bpf_read (dso, cache_offset, cache->data); +else + ret =file_read (dso, machine, cache_offset, cache->data); +if (ret >0 ) { cache->offset = cache_offset; cache->size = ret;
@@ -941,6 +985,9 @@ int dso__data_file_size(struct dso *dso, struct machine *machine)if (dso->data.status ==DSO_DATA_STATUS_ERROR )return -1 ; +if (dso->binary_type ==DSO_BINARY_TYPE__BPF_PROG_INFO ) +return bpf_size (dso); +return file_size (dso, machine); }
Jiri Olsa
reviewerPATCH v3 5/12 perf tools: Read also the end of the kernel
In reply to Jiri OlsaWe mark the end of kernel based on the first module, but that could cover some bpf program maps. Reading _etext symbol if it's present to get precise kernel map end.
--- tools/perf/util/machine.c | 27 ++++++++++++++++++--------- 1 file changed, 18 insertions(+), 9 deletions(-)
tools/perf/util/machine.c +18 -9
@@ -924,7 +924,8 @@ const char *ref_reloc_sym_names[] = {"_text", "_stext", NULL};* symbol_name if it's not that important. */ static int machine__get_running_kernel_start (struct machine *machine, -const char **symbol_name,u64 *start) +const char **symbol_name, +u64 *start,u64 *end) {char filename[PATH_MAX ];int i, err =-1 ;
@@ -949,6 +950,11 @@ static int machine__get_running_kernel_start(struct machine *machine, *symbol_name = name; *start = addr; + + err =kallsyms__get_function_start (filename,"_etext" , &addr); +if (!err) + *end = addr; +return 0 ; }
@@ -1440,7 +1446,7 @@ int machine__create_kernel_maps(struct machine *machine)struct dso *kernel =machine__get_kernel (machine);const char *name =NULL ;struct map *map; -u64 addr =0 ; +u64 start =0 , end = ~0ULL ;int ret;if (kernel ==NULL )
@@ -1459,9 +1465,9 @@ int machine__create_kernel_maps(struct machine *machine) "continuing anyway...\n", machine->pid); } -if (!machine__get_running_kernel_start (machine, &name, &addr)) { +if (!machine__get_running_kernel_start (machine, &name, &start, &end)) {if (name && -map__set_kallsyms_ref_reloc_sym (machine->vmlinux_map, name, addr)) { +map__set_kallsyms_ref_reloc_sym (machine->vmlinux_map, name, start)) {machine__destroy_kernel_maps (machine); ret =-1 ; goto out_put;
@@ -1471,16 +1477,19 @@ int machine__create_kernel_maps(struct machine *machine)* we have a real start address now, so re-order the kmaps * assume it's the last in the kmaps */ -machine__update_kernel_mmap (machine, addr, ~0ULL ); +machine__update_kernel_mmap (machine, start, end); }if (machine__create_extra_kernel_maps (machine, kernel))pr_debug ("Problems creating extra kernel maps, continuing anyway...\n" ); -/* update end address of the kernel map using adjacent module address */ - map =map__next (machine__kernel_map (machine)); -if (map) -machine__set_kernel_mmap (machine, addr, map->start); +if (end == ~0ULL ) { +/* update end address of the kernel map using adjacent module address */ + map =map__next (machine__kernel_map (machine)); +if (map) +machine__set_kernel_mmap (machine, start, map->start); + } + out_put:dso__put (kernel);return ret;
Signature · 1 line
2.20.1
Re: [PATCH 05/12] perf tools: Read also the end of the kernel
Em Wed, May 08, 2019 at 03:20:03PM +0200, Jiri Olsa escreveu:
Quoted 4 lines
We mark the end of kernel based on the first module, but that could cover some bpf program maps. Reading
_etextsymbol if it's present to get precise kernel map end.
Investigating... Have you run 'perf test' before hitting the send button? :-)
- Arnaldo
[root@quaco c]# perf test 1
1: vmlinux symtab matches kallsyms : FAILED!
[root@quaco c]# perf test -v 1
1: vmlinux symtab matches kallsyms :
--- start ---
test child forked, pid 17488
Looking at the vmlinux_path (8 entries long)
Using /lib/modules/5.2.0-rc1+/build/vmlinux for symbols
WARN: 0xffffffff8c001000: diff name v: hypercall_page k: xen_hypercall_set_trap_table
WARN: 0xffffffff8c0275c0: diff name v: __ia32_sys_rt_sigreturn k: __x64_sys_rt_sigreturn
WARN: 0xffffffff8c06ac31: diff name v: end_irq_irq_disable k: start_irq_irq_enable
WARN: 0xffffffff8c06ac32: diff name v: end_irq_irq_enable k: start_irq_restore_fl
WARN: 0xffffffff8c06ac34: diff name v: end_irq_restore_fl k: start_irq_save_fl
WARN: 0xffffffff8c06ac36: diff name v: end_irq_save_fl k: start_mmu_read_cr2
WARN: 0xffffffff8c06ac3c: diff name v: end_mmu_read_cr3 k: start_mmu_write_cr3
WARN: 0xffffffff8c06ac3f: diff name v: end_mmu_write_cr3 k: start_cpu_wbinvd
WARN: 0xffffffff8c06ac41: diff name v: end_cpu_wbinvd k: start_cpu_usergs_sysret64
WARN: 0xffffffff8c06ac47: diff name v: end_cpu_usergs_sysret64 k: start_cpu_swapgs
WARN: 0xffffffff8c06ac4a: diff name v: end_cpu_swapgs k: start__mov64
WARN: 0xffffffff8c0814b0: diff end addr for aesni_gcm_dec v: 0xffffffff8c083606 k: 0xffffffff8c0817c7
WARN: 0xffffffff8c083610: diff end addr for aesni_gcm_enc v: 0xffffffff8c0856f2 k: 0xffffffff8c083927
WARN: 0xffffffff8c085c00: diff end addr for aesni_gcm_enc_update v: 0xffffffff8c087556 k: 0xffffffff8c085c31
WARN: 0xffffffff8c087560: diff end addr for aesni_gcm_dec_update v: 0xffffffff8c088f2a k: 0xffffffff8c087591
WARN: 0xffffffff8c08b7c0: diff end addr for aesni_gcm_enc_update_avx_gen2 v: 0xffffffff8c09b13c k: 0xffffffff8c08b818
WARN: 0xffffffff8c08fac1: diff name v: _initial_blocks_done2259 k: _initial_blocks_encrypted15
WARN: 0xffffffff8c094943: diff name v: _initial_blocks_done4447 k: _initial_blocks_encrypted2497
WARN: 0xffffffff8c09a023: diff name v: _initial_blocks_done7187 k: _initial_blocks_encrypted4649
WARN: 0xffffffff8c09b140: diff end addr for aesni_gcm_dec_update_avx_gen2 v: 0xffffffff8c0ab05f k: 0xffffffff8c09b198
WARN: 0xffffffff8c09f5b6: diff name v: _initial_blocks_done9706 k: _initial_blocks_encrypted7462
WARN: 0xffffffff8c0a4619: diff name v: _initial_blocks_done11894 k: _initial_blocks_encrypted9944
WARN: 0xffffffff8c0a9eda: diff name v: _initial_blocks_done14634 k: _initial_blocks_encrypted12096
WARN: 0xffffffff8c0abcd0: diff end addr for aesni_gcm_enc_update_avx_gen4 v: 0xffffffff8c0ba4a6 k: 0xffffffff8c0abd28
WARN: 0xffffffff8c0afaa5: diff name v: _initial_blocks_done17291 k: _initial_blocks_encrypted15047
WARN: 0xffffffff8c0b4345: diff name v: _initial_blocks_done19479 k: _initial_blocks_encrypted17529
WARN: 0xffffffff8c0b9443: diff name v: _initial_blocks_done22219 k: _initial_blocks_encrypted19681
WARN: 0xffffffff8c0ba4b0: diff end addr for aesni_gcm_dec_update_avx_gen4 v: 0xffffffff8c0c9229 k: 0xffffffff8c0ba508
WARN: 0xffffffff8c0be3fa: diff name v: _initial_blocks_done24738 k: _initial_blocks_encrypted22494
WARN: 0xffffffff8c0c2e7b: diff name v: _initial_blocks_done26926 k: _initial_blocks_encrypted24976
WARN: 0xffffffff8c0c815a: diff name v: _initial_blocks_done29666 k: _initial_blocks_encrypted27128
WARN: 0xffffffff8c0dc2b0: diff name v: __ia32_sys_fork k: __x64_sys_fork
WARN: 0xffffffff8c0dc2d0: diff name v: __ia32_sys_vfork k: __x64_sys_vfork
WARN: 0xffffffff8c0e9eb0: diff name v: __ia32_sys_restart_syscall k: __x64_sys_restart_syscall
WARN: 0xffffffff8c0e9f30: diff name v: __ia32_sys_sgetmask k: __x64_sys_sgetmask
WARN: 0xffffffff8c0ea4b0: diff name v: __ia32_sys_pause k: __x64_sys_pause
WARN: 0xffffffff8c0f1610: diff name v: __ia32_sys_gettid k: __x64_sys_gettid
WARN: 0xffffffff8c0f1630: diff name v: __ia32_sys_getpid k: __x64_sys_getpid
WARN: 0xffffffff8c0f1650: diff name v: __ia32_sys_getppid k: __x64_sys_getppid
WARN: 0xffffffff8c0f1980: diff name v: __ia32_sys_getuid k: __x64_sys_getuid
WARN: 0xffffffff8c0f19b0: diff name v: __ia32_sys_geteuid k: __x64_sys_geteuid
WARN: 0xffffffff8c0f1b30: diff name v: __ia32_sys_getgid k: __x64_sys_getgid
WARN: 0xffffffff8c0f1b60: diff name v: __ia32_sys_getegid k: __x64_sys_getegid
WARN: 0xffffffff8c0f2130: diff name v: __ia32_sys_getpgrp k: __x64_sys_getpgrp
WARN: 0xffffffff8c0f52f0: diff name v: __ia32_sys_setsid k: __x64_sys_setsid
WARN: 0xffffffff8c1016d0: diff name v: sys_ni_syscall k: __x64_sys_vm86old
WARN: 0xffffffff8c10b400: diff name v: __ia32_sys_sched_yield k: __x64_sys_sched_yield
WARN: 0xffffffff8c1775a0: diff name v: __ia32_sys_getuid16 k: __x64_sys_getuid16
WARN: 0xffffffff8c1775f0: diff name v: __ia32_sys_geteuid16 k: __x64_sys_geteuid16
WARN: 0xffffffff8c177640: diff name v: __ia32_sys_getgid16 k: __x64_sys_getgid16
WARN: 0xffffffff8c177690: diff name v: __ia32_sys_getegid16 k: __x64_sys_getegid16
WARN: 0xffffffff8c1fa600: diff name v: mark_reg_not_init.part.48 k: mark_reg_unknown.part.51
WARN: 0xffffffff8c21c1f0: diff name v: perf_pmu_cancel_txn.part.104 k: perf_pmu_commit_txn.part.105
WARN: 0xffffffff8c23cad0: diff name v: __probe_kernel_read k: probe_kernel_read
WARN: 0xffffffff8c23cb50: diff name v: __probe_kernel_write k: probe_kernel_write
WARN: 0xffffffff8c277720: diff name v: __ia32_sys_munlockall k: __x64_sys_munlockall
WARN: 0xffffffff8c2e9a70: diff name v: __ia32_sys_vhangup k: __x64_sys_vhangup
WARN: 0xffffffff8c325d30: diff name v: __ia32_sys_sync k: __x64_sys_sync
WARN: 0xffffffff8c33c310: diff name v: __ia32_sys_inotify_init k: __x64_sys_inotify_init
WARN: 0xffffffff8c42be70: diff name v: selinux_msg_queue_msgctl.part.37 k: selinux_shm_shmctl.part.36
WARN: 0xffffffff8c4574c0: diff name v: _rsa_dec.isra.2 k: _rsa_enc.isra.3
WARN: 0xffffffff8c4c84e0: diff name v: __crc32c_le_base k: __crc32c_le
WARN: 0xffffffff8c4c8630: diff name v: crc32_le_base k: crc32_le
WARN: 0xffffffff8c516041: diff name v: quirk_disable_msi.part.30 k: quirk_msi_ht_cap.part.43
WARN: 0xffffffff8c596c80: diff name v: clkdev_hw_create k: __clk_register_clkdev
WARN: 0xffffffff8c844430: diff name v: phys_switch_id_show.part.17 k: speed_show.part.22
WARN: 0xffffffff8c8578f0: diff name v: devlink_fmsg_arr_pair_nest_end.part.56 k: devlink_fmsg_u8_pair_put.part.60
WARN: 0xffffffff8c9961d0: diff name v: __memcpy k: memcpy
WARN: 0xffffffff8c996370: diff name v: __memmove k: memmove
WARN: 0xffffffff8c996510: diff name v: __memset k: memset
WARN: 0xffffffff8c996b90: diff end addr for csum_partial_copy_generic v: 0xffffffff8c996cf9 k: 0xffffffff8c999590
WARN: 0xffffffff8c9a6e50: diff name v: default_idle k: __cpuidle_text_start
WARN: 0xffffffff8ca00000: diff name v: native_usergs_sysret64 k: __entry_text_start
WARN: 0xffffffff8ca00a3b: diff name v: restore_regs_and_return_to_kernel k: retint_kernel
ERR : 0xffffffff8cc00e41: __indirect_thunk_end not on kallsyms
WARN: Maps only in vmlinux:
b000000-b02c000 1c00000 [kernel].data..percpu
ffffffff8cc00e44-ffffffff8cc01044 e00e44 [kernel].notes
ffffffff8ce00000-ffffffff8d1c9372 1000000 [kernel].rodata
ffffffff8d1cbfb0-ffffffff8d1cc028 13cbfb0 [kernel].tracedata
ffffffff8d1e04d0-ffffffff8d2123a0 13e04d0 [kernel]__ksymtab_strings ffffffff8d2123a0-ffffffff8d2125d0 14123a0 [kernel]__init_rodata
ffffffff8d2125d0-ffffffff8d215bb8 14125d0 [kernel]__param
ffffffff8d215bb8-ffffffff8d216000 1415bb8 [kernel]__modver
ffffffff8d400000-ffffffff8d5679c0 1600000 [kernel].data
ffffffff8d933000-ffffffff8d934000 1b33000 [kernel].vvar
ffffffff8d960000-ffffffff8d9dcb2f 1d60000 [kernel].init.text
ffffffff8d9de000-ffffffff8db46590 1dde000 [kernel].init.data
ffffffff8db46590-ffffffff8db465b0 1f46590 [kernel].x86_cpu_dev.init ffffffff8db5ded0-ffffffff8db5df98 1f5ded0 [kernel].iommu_table
ffffffff8db5df98-ffffffff8db5dfd8 1f5df98 [kernel].apicdrivers
ffffffff8db5dfd8-ffffffff8db5f85e 1f5dfd8 [kernel].exit.text
ffffffff8db69000-ffffffff8db6a000 1f69000 [kernel].data_nosave
ffffffff8db6a000-ffffffff8e000000 1f6a000 [kernel].bss
test child finished with -1
---- end ----
vmlinux symtab matches kallsyms: FAILED!
[root@quaco c]#
[acme@quaco perf]$ git bisect good 7d98e1a73bd7dae6cb321ec8b0b97b9fed7c0e1b is the first bad commit commit 7d98e1a73bd7dae6cb321ec8b0b97b9fed7c0e1b
Author: Jiri Olsa <[email protected]> Date: Wed May 8 15:20:03 2019 +0200
perf machine: Read also the end of the kernel
We mark the end of kernel based on the first module, but that could cover some bpf program maps. Reading _etext symbol if it's present to get precise kernel map end.
:040000 040000 4ca5fa4c6f15fd8cf9a0eee870efbd01e9fe309d 8311b30f94e9cf9a863dc9619b0499863f64960e M tools
[acme@quaco perf]$
Quoted 80 lines
Signed-off-by Jiri Olsa <[email protected]>--- tools/perf/util/machine.c | 27 ++++++++++++++++++--------- 1 file changed, 18 insertions(+), 9 deletions(-)tools/perf/util/machine.c +18
-9@@ -924,7 +924,8 @@ const char *ref_reloc_sym_names[] = {"_text", "_stext", NULL};* symbol_name if it's not that important. */ static int machine__get_running_kernel_start (struct machine *machine, -const char **symbol_name,u64 *start) +const char **symbol_name, +u64 *start,u64 *end) {char filename[PATH_MAX ];int i, err =-1 ;@@ -949,6 +950,11 @@ static int machine__get_running_kernel_start(struct machine *machine, *symbol_name = name; *start = addr; + + err =kallsyms__get_function_start (filename,"_etext" , &addr); +if (!err) + *end = addr; +return 0 ; }@@ -1440,7 +1446,7 @@ int machine__create_kernel_maps(struct machine *machine)struct dso *kernel =machine__get_kernel (machine);const char *name =NULL ;struct map *map; -u64 addr =0 ; +u64 start =0 , end = ~0ULL ;int ret;if (kernel ==NULL )@@ -1459,9 +1465,9 @@ int machine__create_kernel_maps(struct machine *machine) "continuing anyway...\n", machine->pid); } -if (!machine__get_running_kernel_start (machine, &name, &addr)) { +if (!machine__get_running_kernel_start (machine, &name, &start, &end)) {if (name && -map__set_kallsyms_ref_reloc_sym (machine->vmlinux_map, name, addr)) { +map__set_kallsyms_ref_reloc_sym (machine->vmlinux_map, name, start)) {machine__destroy_kernel_maps (machine); ret =-1 ; goto out_put;@@ -1471,16 +1477,19 @@ int machine__create_kernel_maps(struct machine *machine)* we have a real start address now, so re-order the kmaps * assume it's the last in the kmaps */ -machine__update_kernel_mmap (machine, addr, ~0ULL ); +machine__update_kernel_mmap (machine, start, end); }if (machine__create_extra_kernel_maps (machine, kernel))pr_debug ("Problems creating extra kernel maps, continuing anyway...\n" ); -/* update end address of the kernel map using adjacent module address */ - map =map__next (machine__kernel_map (machine)); -if (map) -machine__set_kernel_mmap (machine, addr, map->start); +if (end == ~0ULL ) { +/* update end address of the kernel map using adjacent module address */ + map =map__next (machine__kernel_map (machine)); +if (map) +machine__set_kernel_mmap (machine, start, map->start); + } + out_put:dso__put (kernel);return ret;Signature · 1 line
2.20.1
Signature · 1 line
- Arnaldo
Re: [PATCH 05/12] perf tools: Read also the end of the kernel
Em Fri, May 24, 2019 at 03:15:06PM -0300, Arnaldo Carvalho de Melo escreveu:
Quoted 8 lines
Em Wed, May 08, 2019 at 03:20:03PM +0200, Jiri Olsa escreveu:
Quoted 4 lines
We mark the end of kernel based on the first module, but that could cover some bpf program maps. Reading
_etextsymbol if it's present to get precise kernel map end.Investigating... Have you run 'perf test' before hitting the send button? :-)
<SNIP>
Quoted 2 lines
[root@quaco c]# perf test -v 1
1: vmlinux symtab matches kallsyms :
<SNIP>
Quoted 2 lines
--- start ---
ERR :0xffffffff8cc00e41:__indirect_thunk_endnot on kallsyms
<SNIP>
Quoted 4 lines
test child finished with -1
---- end ----
vmlinux symtab matches kallsyms: FAILED!
[root@quaco c]#
So...
[root@quaco c]# grep __indirect_thunk_end /proc/kallsyms ffffffff8cc00e41 T __indirect_thunk_end [root@quaco c]# grep -w _etext /proc/kallsyms ffffffff8cc00e41 T _etext
[root@quaco c]#
[root@quaco c]# grep -w ffffffff8cc00e41 /proc/kallsyms ffffffff8cc00e41 T _etextffffffff8cc00e41 T __indirect_thunk_end [root@quaco c]#
Lemme try to fix this.
- Arnaldo
Quoted 111 lines
[acme@quaco perf]$ git bisect good
7d98e1a73bd7dae6cb321ec8b0b97b9fed7c0e1bis the first bad commit commit7d98e1a73bd7dae6cb321ec8b0b97b9fed7c0e1bAuthor: Jiri Olsa <[email protected]> Date: Wed May 8 15:20:03 2019 +0200perf machine: Read also the end of the kernel
We mark the end of kernel based on the first module, but that could cover some bpf program maps. Reading
_etextsymbol if it's present to get precise kernel map end.Signed-off-by Jiri Olsa <[email protected]>Acked-by Song Liu <[email protected]>Cc Adrian Hunter <[email protected]>Cc Alexander Shishkin <[email protected]>Cc Andi Kleen <[email protected]>Cc Namhyung Kim <[email protected]>Cc Peter Zijlstra <[email protected]>Cc Stanislav Fomichev <[email protected]>Cc Thomas Richter <[email protected]>Signed-off-by Arnaldo Carvalho de Melo <[email protected]>:040000 040000
4ca5fa4c6f15fd8cf9a0eee870efbd01e9fe309d8311b30f94e9cf9a863dc9619b0499863f64960eM tools
[acme@quaco perf]$Quoted 80 lines
Signed-off-by Jiri Olsa <[email protected]>--- tools/perf/util/machine.c | 27 ++++++++++++++++++--------- 1 file changed, 18 insertions(+), 9 deletions(-)tools/perf/util/machine.c +18
-9@@ -924,7 +924,8 @@ const char *ref_reloc_sym_names[] = {"_text", "_stext", NULL};* symbol_name if it's not that important. */ static int machine__get_running_kernel_start (struct machine *machine, -const char **symbol_name,u64 *start) +const char **symbol_name, +u64 *start,u64 *end) {char filename[PATH_MAX ];int i, err =-1 ;@@ -949,6 +950,11 @@ static int machine__get_running_kernel_start(struct machine *machine, *symbol_name = name; *start = addr; + + err =kallsyms__get_function_start (filename,"_etext" , &addr); +if (!err) + *end = addr; +return 0 ; }@@ -1440,7 +1446,7 @@ int machine__create_kernel_maps(struct machine *machine)struct dso *kernel =machine__get_kernel (machine);const char *name =NULL ;struct map *map; -u64 addr =0 ; +u64 start =0 , end = ~0ULL ;int ret;if (kernel ==NULL )@@ -1459,9 +1465,9 @@ int machine__create_kernel_maps(struct machine *machine) "continuing anyway...\n", machine->pid); } -if (!machine__get_running_kernel_start (machine, &name, &addr)) { +if (!machine__get_running_kernel_start (machine, &name, &start, &end)) {if (name && -map__set_kallsyms_ref_reloc_sym (machine->vmlinux_map, name, addr)) { +map__set_kallsyms_ref_reloc_sym (machine->vmlinux_map, name, start)) {machine__destroy_kernel_maps (machine); ret =-1 ; goto out_put;@@ -1471,16 +1477,19 @@ int machine__create_kernel_maps(struct machine *machine)* we have a real start address now, so re-order the kmaps * assume it's the last in the kmaps */ -machine__update_kernel_mmap (machine, addr, ~0ULL ); +machine__update_kernel_mmap (machine, start, end); }if (machine__create_extra_kernel_maps (machine, kernel))pr_debug ("Problems creating extra kernel maps, continuing anyway...\n" ); -/* update end address of the kernel map using adjacent module address */ - map =map__next (machine__kernel_map (machine)); -if (map) -machine__set_kernel_mmap (machine, addr, map->start); +if (end == ~0ULL ) { +/* update end address of the kernel map using adjacent module address */ + map =map__next (machine__kernel_map (machine)); +if (map) +machine__set_kernel_mmap (machine, start, map->start); + } + out_put:dso__put (kernel);return ret;Signature · 1 line
2.20.1Signature · 1 line
- Arnaldo
Signature · 1 line
- Arnaldo
Re: [PATCH 05/12] perf tools: Read also the end of the kernel
Em Fri, May 24, 2019 at 03:17:17PM -0300, Arnaldo Carvalho de Melo escreveu:
Quoted 31 lines
Em Fri, May 24, 2019 at 03:15:06PM -0300, Arnaldo Carvalho de Melo escreveu:
Quoted 8 lines
Em Wed, May 08, 2019 at 03:20:03PM +0200, Jiri Olsa escreveu:
Quoted 4 lines
We mark the end of kernel based on the first module, but that could cover some bpf program maps. Reading
_etextsymbol if it's present to get precise kernel map end.Investigating... Have you run 'perf test' before hitting the send button? :-)
<SNIP>
Quoted 2 lines
[root@quaco c]# perf test -v 1
1: vmlinux symtab matches kallsyms :<SNIP>
Quoted 2 lines
--- start ---
ERR :0xffffffff8cc00e41:__indirect_thunk_endnot on kallsyms<SNIP>
Quoted 4 lines
test child finished with -1
---- end ----
vmlinux symtab matches kallsyms: FAILED!
[root@quaco c]#So...
[root@quaco c]# grep
__indirect_thunk_end/proc/kallsymsffffffff8cc00e41T__indirect_thunk_end[root@quaco c]# grep -w_etext/proc/kallsymsffffffff8cc00e41T_etext
[root@quaco c]#
Quoted 6 lines
[root@quaco c]# grep -w
ffffffff8cc00e41/proc/kallsymsffffffff8cc00e41T_etextffffffff8cc00e41T__indirect_thunk_end[root@quaco c]#Lemme try to fix this.
So, I got this right before your patch:
commit 1d1c54c5bbf55256e691bedb47b0d14745043e80
Author: Arnaldo Carvalho de Melo <[email protected]> Date: Fri May 24 15:39:00 2019 -0300
perf test vmlinux-kallsyms: Ignore aliases to _etext when searching on kallsyms
No need to search for aliases for the symbol that marks the end of the kernel text segment, the following patch will make such symbols not to be found when searching in the kallsyms maps causing this test to fail.
So as a prep patch to avoid breaking bisection, ignore such symbols.
tools/perf/tests/vmlinux-kallsyms.c +8 -1
@@ -161,9 +161,16 @@ int test__vmlinux_matches_kallsyms(struct test *test __maybe_unused, int subtestcontinue ; } - }else + }else if (mem_start == kallsyms.vmlinux_map->end) { +/* +* Ignore aliases to _etext, i.e. to the end of the kernel text area, +* such as __indirect_thunk_end. +*/ +continue ; + }else {pr_debug ("ERR : %#" PRIx64": %s not on kallsyms\n" , mem_start, sym->name); + } err =-1 ; }
Jiri Olsa
Tested-byRe: [PATCH 05/12] perf tools: Read also the end of the kernel
Quoted 53 lines · Arnaldo Carvalho de Melo
Em Fri, May 24, 2019 at 03:17:17PM -0300, Arnaldo Carvalho de Melo escreveu:
Quoted 31 lines
Em Fri, May 24, 2019 at 03:15:06PM -0300, Arnaldo Carvalho de Melo escreveu:
Quoted 8 lines
Em Wed, May 08, 2019 at 03:20:03PM +0200, Jiri Olsa escreveu:
Quoted 4 lines
We mark the end of kernel based on the first module, but that could cover some bpf program maps. Reading
_etextsymbol if it's present to get precise kernel map end.Investigating... Have you run 'perf test' before hitting the send button? :-)
<SNIP>
Quoted 2 lines
[root@quaco c]# perf test -v 1
1: vmlinux symtab matches kallsyms :<SNIP>
Quoted 2 lines
--- start ---
ERR :0xffffffff8cc00e41:__indirect_thunk_endnot on kallsyms<SNIP>
Quoted 4 lines
test child finished with -1
---- end ----
vmlinux symtab matches kallsyms: FAILED!
[root@quaco c]#So...
[root@quaco c]# grep
__indirect_thunk_end/proc/kallsymsffffffff8cc00e41T__indirect_thunk_end[root@quaco c]# grep -w_etext/proc/kallsymsffffffff8cc00e41T_etext
[root@quaco c]#Quoted 6 lines
[root@quaco c]# grep -w
ffffffff8cc00e41/proc/kallsymsffffffff8cc00e41T_etextffffffff8cc00e41T__indirect_thunk_end[root@quaco c]#Lemme try to fix this.
So, I got this right before your patch:
commit
1d1c54c5bbf55256e691bedb47b0d14745043e80Author: Arnaldo Carvalho de Melo <[email protected]> Date: Fri May 24 15:39:00 2019 -0300perf test vmlinux-kallsyms: Ignore aliases to
_etextwhen searching on kallsymsNo need to search for aliases for the symbol that marks the end of the kernel text segment, the following patch will make such symbols not to be found when searching in the kallsyms maps causing this test to fail.
So as a prep patch to avoid breaking bisection, ignore such symbols.
Quoted 11 lines
Cc Adrian Hunter <[email protected]>Cc Alexander Shishkin <[email protected]>Cc Andi Kleen <[email protected]>Cc Jiri Olsa <[email protected]>Cc Namhyung Kim <[email protected]>Cc Peter Zijlstra <[email protected]>Cc Song Liu <[email protected]>Cc Stanislav Fomichev <[email protected]>Cc Thomas Richter <[email protected]>Signed-off-by Arnaldo Carvalho de Melo <[email protected]>
works for me
thanks,
jirka
Re: [PATCH 05/12] perf tools: Read also the end of the kernel
In reply to Arnaldo Carvalho de MeloQuoted 8 lines · Arnaldo Carvalho de Melo
Em Wed, May 08, 2019 at 03:20:03PM +0200, Jiri Olsa escreveu:
Quoted 4 lines
We mark the end of kernel based on the first module, but that could cover some bpf program maps. Reading
_etextsymbol if it's present to get precise kernel map end.Investigating... Have you run 'perf test' before hitting the send button? :-)
yea, I got skip test.. for not having the vmlinux in place
[jolsa@krava perf]$ sudo ./perf test 1
1: vmlinux symtab matches kallsyms : Skip
did not realized it would break.. because I have 'Skip' in this one always :-\ sry
jirka
Quoted 221 lines
- Arnaldo
[root@quaco c]# perf test 1
1: vmlinux symtab matches kallsyms : FAILED!
[root@quaco c]# perf test -v 1
1: vmlinux symtab matches kallsyms :
--- start ---
test child forked, pid 17488
Looking at thevmlinux_path(8 entries long)
Using/lib/modules/5.2.0-rc1+/build/vmlinuxfor symbols
WARN:0xffffffff8c001000: diff name v:hypercall_pagek:xen_hypercall_set_trap_table
WARN:0xffffffff8c0275c0: diff name v:__ia32_sys_rt_sigreturnk:__x64_sys_rt_sigreturn
WARN:0xffffffff8c06ac31: diff name v:end_irq_irq_disablek:start_irq_irq_enable
WARN:0xffffffff8c06ac32: diff name v:end_irq_irq_enablek:start_irq_restore_fl
WARN:0xffffffff8c06ac34: diff name v:end_irq_restore_flk:start_irq_save_fl
WARN:0xffffffff8c06ac36: diff name v:end_irq_save_flk:start_mmu_read_cr2
WARN:0xffffffff8c06ac3c: diff name v:end_mmu_read_cr3k:start_mmu_write_cr3
WARN:0xffffffff8c06ac3f: diff name v:end_mmu_write_cr3k:start_cpu_wbinvd
WARN:0xffffffff8c06ac41: diff name v:end_cpu_wbinvdk:start_cpu_usergs_sysret64
WARN:0xffffffff8c06ac47: diff name v:end_cpu_usergs_sysret64k:start_cpu_swapgs
WARN:0xffffffff8c06ac4a: diff name v:end_cpu_swapgsk:start__mov64
WARN:0xffffffff8c0814b0: diff end addr foraesni_gcm_decv:0xffffffff8c083606k:0xffffffff8c0817c7
WARN:0xffffffff8c083610: diff end addr foraesni_gcm_encv:0xffffffff8c0856f2k:0xffffffff8c083927
WARN:0xffffffff8c085c00: diff end addr foraesni_gcm_enc_updatev:0xffffffff8c087556k:0xffffffff8c085c31
WARN:0xffffffff8c087560: diff end addr foraesni_gcm_dec_updatev:0xffffffff8c088f2ak:0xffffffff8c087591
WARN:0xffffffff8c08b7c0: diff end addr foraesni_gcm_enc_update_avx_gen2v:0xffffffff8c09b13ck:0xffffffff8c08b818
WARN:0xffffffff8c08fac1: diff name v:_initial_blocks_done2259k:_initial_blocks_encrypted15
WARN:0xffffffff8c094943: diff name v:_initial_blocks_done4447k:_initial_blocks_encrypted2497
WARN:0xffffffff8c09a023: diff name v:_initial_blocks_done7187k:_initial_blocks_encrypted4649
WARN:0xffffffff8c09b140: diff end addr foraesni_gcm_dec_update_avx_gen2v:0xffffffff8c0ab05fk:0xffffffff8c09b198
WARN:0xffffffff8c09f5b6: diff name v:_initial_blocks_done9706k:_initial_blocks_encrypted7462
WARN:0xffffffff8c0a4619: diff name v:_initial_blocks_done11894k:_initial_blocks_encrypted9944
WARN:0xffffffff8c0a9eda: diff name v:_initial_blocks_done14634k:_initial_blocks_encrypted12096
WARN:0xffffffff8c0abcd0: diff end addr foraesni_gcm_enc_update_avx_gen4v:0xffffffff8c0ba4a6k:0xffffffff8c0abd28
WARN:0xffffffff8c0afaa5: diff name v:_initial_blocks_done17291k:_initial_blocks_encrypted15047
WARN:0xffffffff8c0b4345: diff name v:_initial_blocks_done19479k:_initial_blocks_encrypted17529
WARN:0xffffffff8c0b9443: diff name v:_initial_blocks_done22219k:_initial_blocks_encrypted19681
WARN:0xffffffff8c0ba4b0: diff end addr foraesni_gcm_dec_update_avx_gen4v:0xffffffff8c0c9229k:0xffffffff8c0ba508
WARN:0xffffffff8c0be3fa: diff name v:_initial_blocks_done24738k:_initial_blocks_encrypted22494
WARN:0xffffffff8c0c2e7b: diff name v:_initial_blocks_done26926k:_initial_blocks_encrypted24976
WARN:0xffffffff8c0c815a: diff name v:_initial_blocks_done29666k:_initial_blocks_encrypted27128
WARN:0xffffffff8c0dc2b0: diff name v:__ia32_sys_forkk:__x64_sys_fork
WARN:0xffffffff8c0dc2d0: diff name v:__ia32_sys_vforkk:__x64_sys_vfork
WARN:0xffffffff8c0e9eb0: diff name v:__ia32_sys_restart_syscallk:__x64_sys_restart_syscall
WARN:0xffffffff8c0e9f30: diff name v:__ia32_sys_sgetmaskk:__x64_sys_sgetmask
WARN:0xffffffff8c0ea4b0: diff name v:__ia32_sys_pausek:__x64_sys_pause
WARN:0xffffffff8c0f1610: diff name v:__ia32_sys_gettidk:__x64_sys_gettid
WARN:0xffffffff8c0f1630: diff name v:__ia32_sys_getpidk:__x64_sys_getpid
WARN:0xffffffff8c0f1650: diff name v:__ia32_sys_getppidk:__x64_sys_getppid
WARN:0xffffffff8c0f1980: diff name v:__ia32_sys_getuidk:__x64_sys_getuid
WARN:0xffffffff8c0f19b0: diff name v:__ia32_sys_geteuidk:__x64_sys_geteuid
WARN:0xffffffff8c0f1b30: diff name v:__ia32_sys_getgidk:__x64_sys_getgid
WARN:0xffffffff8c0f1b60: diff name v:__ia32_sys_getegidk:__x64_sys_getegid
WARN:0xffffffff8c0f2130: diff name v:__ia32_sys_getpgrpk:__x64_sys_getpgrp
WARN:0xffffffff8c0f52f0: diff name v:__ia32_sys_setsidk:__x64_sys_setsid
WARN:0xffffffff8c1016d0: diff name v:sys_ni_syscallk:__x64_sys_vm86old
WARN:0xffffffff8c10b400: diff name v:__ia32_sys_sched_yieldk:__x64_sys_sched_yield
WARN:0xffffffff8c1775a0: diff name v:__ia32_sys_getuid16k:__x64_sys_getuid16
WARN:0xffffffff8c1775f0: diff name v:__ia32_sys_geteuid16k:__x64_sys_geteuid16
WARN:0xffffffff8c177640: diff name v:__ia32_sys_getgid16k:__x64_sys_getgid16
WARN:0xffffffff8c177690: diff name v:__ia32_sys_getegid16k:__x64_sys_getegid16
WARN:0xffffffff8c1fa600: diff name v: mark_reg_not_init.part.48 k: mark_reg_unknown.part.51
WARN:0xffffffff8c21c1f0: diff name v: perf_pmu_cancel_txn.part.104 k: perf_pmu_commit_txn.part.105
WARN:0xffffffff8c23cad0: diff name v:__probe_kernel_readk:probe_kernel_read
WARN:0xffffffff8c23cb50: diff name v:__probe_kernel_writek:probe_kernel_write
WARN:0xffffffff8c277720: diff name v:__ia32_sys_munlockallk:__x64_sys_munlockall
WARN:0xffffffff8c2e9a70: diff name v:__ia32_sys_vhangupk:__x64_sys_vhangup
WARN:0xffffffff8c325d30: diff name v:__ia32_sys_synck:__x64_sys_sync
WARN:0xffffffff8c33c310: diff name v:__ia32_sys_inotify_initk:__x64_sys_inotify_init
WARN:0xffffffff8c42be70: diff name v: selinux_msg_queue_msgctl.part.37 k: selinux_shm_shmctl.part.36
WARN:0xffffffff8c4574c0: diff name v: _rsa_dec.isra.2 k: _rsa_enc.isra.3
WARN:0xffffffff8c4c84e0: diff name v:__crc32c_le_basek:__crc32c_le
WARN:0xffffffff8c4c8630: diff name v:crc32_le_basek:crc32_le
WARN:0xffffffff8c516041: diff name v: quirk_disable_msi.part.30 k: quirk_msi_ht_cap.part.43
WARN:0xffffffff8c596c80: diff name v:clkdev_hw_createk:__clk_register_clkdev
WARN:0xffffffff8c844430: diff name v: phys_switch_id_show.part.17 k: speed_show.part.22
WARN:0xffffffff8c8578f0: diff name v: devlink_fmsg_arr_pair_nest_end.part.56 k: devlink_fmsg_u8_pair_put.part.60
WARN:0xffffffff8c9961d0: diff name v:__memcpyk: memcpy
WARN:0xffffffff8c996370: diff name v:__memmovek: memmove
WARN:0xffffffff8c996510: diff name v:__memsetk: memset
WARN:0xffffffff8c996b90: diff end addr forcsum_partial_copy_genericv:0xffffffff8c996cf9k:0xffffffff8c999590
WARN:0xffffffff8c9a6e50: diff name v:default_idlek:__cpuidle_text_start
WARN:0xffffffff8ca00000: diff name v:native_usergs_sysret64k:__entry_text_start
WARN:0xffffffff8ca00a3b: diff name v:restore_regs_and_return_to_kernelk:retint_kernel
ERR :0xffffffff8cc00e41:__indirect_thunk_endnot on kallsyms
WARN: Maps only in vmlinux:
b000000-b02c000 1c00000 [kernel].data..percpu
ffffffff8cc00e44-ffffffff8cc01044 e00e44 [kernel].notes
ffffffff8ce00000-ffffffff8d1c9372 1000000 [kernel].rodata
ffffffff8d1cbfb0-ffffffff8d1cc028 13cbfb0 [kernel].tracedata
ffffffff8d1e04d0-ffffffff8d2123a0 13e04d0 [kernel]__ksymtab_strings ffffffff8d2123a0-ffffffff8d2125d0 14123a0 [kernel]__init_rodata
ffffffff8d2125d0-ffffffff8d215bb8 14125d0 [kernel]__param
ffffffff8d215bb8-ffffffff8d216000 1415bb8 [kernel]__modver
ffffffff8d400000-ffffffff8d5679c0 1600000 [kernel].data
ffffffff8d933000-ffffffff8d934000 1b33000 [kernel].vvar
ffffffff8d960000-ffffffff8d9dcb2f 1d60000 [kernel].init.text
ffffffff8d9de000-ffffffff8db46590 1dde000 [kernel].init.data
ffffffff8db46590-ffffffff8db465b0 1f46590 [kernel].x86_cpu_dev.init ffffffff8db5ded0-ffffffff8db5df98 1f5ded0 [kernel].iommu_table
ffffffff8db5df98-ffffffff8db5dfd8 1f5df98 [kernel].apicdrivers
ffffffff8db5dfd8-ffffffff8db5f85e 1f5dfd8 [kernel].exit.text
ffffffff8db69000-ffffffff8db6a000 1f69000 [kernel].data_nosave
ffffffff8db6a000-ffffffff8e000000 1f6a000 [kernel].bss
test child finished with -1
---- end ----
vmlinux symtab matches kallsyms: FAILED!
[root@quaco c]#[acme@quaco perf]$ git bisect good
7d98e1a73bd7dae6cb321ec8b0b97b9fed7c0e1bis the first bad commit commit7d98e1a73bd7dae6cb321ec8b0b97b9fed7c0e1bAuthor: Jiri Olsa <[email protected]> Date: Wed May 8 15:20:03 2019 +0200perf machine: Read also the end of the kernel
We mark the end of kernel based on the first module, but that could cover some bpf program maps. Reading
_etextsymbol if it's present to get precise kernel map end.Signed-off-by Jiri Olsa <[email protected]>Acked-by Song Liu <[email protected]>Cc Adrian Hunter <[email protected]>Cc Alexander Shishkin <[email protected]>Cc Andi Kleen <[email protected]>Cc Namhyung Kim <[email protected]>Cc Peter Zijlstra <[email protected]>Cc Stanislav Fomichev <[email protected]>Cc Thomas Richter <[email protected]>Signed-off-by Arnaldo Carvalho de Melo <[email protected]>:040000 040000
4ca5fa4c6f15fd8cf9a0eee870efbd01e9fe309d8311b30f94e9cf9a863dc9619b0499863f64960eM tools
[acme@quaco perf]$Quoted 80 lines
Signed-off-by Jiri Olsa <[email protected]>--- tools/perf/util/machine.c | 27 ++++++++++++++++++--------- 1 file changed, 18 insertions(+), 9 deletions(-)tools/perf/util/machine.c +18
-9@@ -924,7 +924,8 @@ const char *ref_reloc_sym_names[] = {"_text", "_stext", NULL};* symbol_name if it's not that important. */ static int machine__get_running_kernel_start (struct machine *machine, -const char **symbol_name,u64 *start) +const char **symbol_name, +u64 *start,u64 *end) {char filename[PATH_MAX ];int i, err =-1 ;@@ -949,6 +950,11 @@ static int machine__get_running_kernel_start(struct machine *machine, *symbol_name = name; *start = addr; + + err =kallsyms__get_function_start (filename,"_etext" , &addr); +if (!err) + *end = addr; +return 0 ; }@@ -1440,7 +1446,7 @@ int machine__create_kernel_maps(struct machine *machine)struct dso *kernel =machine__get_kernel (machine);const char *name =NULL ;struct map *map; -u64 addr =0 ; +u64 start =0 , end = ~0ULL ;int ret;if (kernel ==NULL )@@ -1459,9 +1465,9 @@ int machine__create_kernel_maps(struct machine *machine) "continuing anyway...\n", machine->pid); } -if (!machine__get_running_kernel_start (machine, &name, &addr)) { +if (!machine__get_running_kernel_start (machine, &name, &start, &end)) {if (name && -map__set_kallsyms_ref_reloc_sym (machine->vmlinux_map, name, addr)) { +map__set_kallsyms_ref_reloc_sym (machine->vmlinux_map, name, start)) {machine__destroy_kernel_maps (machine); ret =-1 ; goto out_put;@@ -1471,16 +1477,19 @@ int machine__create_kernel_maps(struct machine *machine)* we have a real start address now, so re-order the kmaps * assume it's the last in the kmaps */ -machine__update_kernel_mmap (machine, addr, ~0ULL ); +machine__update_kernel_mmap (machine, start, end); }if (machine__create_extra_kernel_maps (machine, kernel))pr_debug ("Problems creating extra kernel maps, continuing anyway...\n" ); -/* update end address of the kernel map using adjacent module address */ - map =map__next (machine__kernel_map (machine)); -if (map) -machine__set_kernel_mmap (machine, addr, map->start); +if (end == ~0ULL ) { +/* update end address of the kernel map using adjacent module address */ + map =map__next (machine__kernel_map (machine)); +if (map) +machine__set_kernel_mmap (machine, start, map->start); + } + out_put:dso__put (kernel);return ret;Signature · 1 line
2.20.1Signature · 1 line
- Arnaldo
tip-bot for Jiri Olsa
merge bot[tip:perf/urgent] perf machine: Read also the end of the kernel
In reply to Jiri Olsaperf machine: Read also the end of the kernel
Commit-ID: ed9adb2035b5be5896d465b19040262be5f4a824 Gitweb: https://git.kernel.org/tip/ed9adb2035b5be5896d465b19040262be5f4a824 Author: Jiri Olsa <[email protected]> AuthorDate: Wed, 8 May 2019 15:20:03 +0200 Committer: Arnaldo Carvalho de Melo <[email protected]> CommitDate: Tue, 28 May 2019 09:52:23 -0300
perf machine: Read also the end of the kernel
We mark the end of kernel based on the first module, but that could cover some bpf program maps. Reading _etext symbol if it's present to get precise kernel map end.
--- tools/perf/util/machine.c | 27 ++++++++++++++++++--------- 1 file changed, 18 insertions(+), 9 deletions(-)
tools/perf/util/machine.c +18 -9
@@ -924,7 +924,8 @@ const char *ref_reloc_sym_names[] = {"_text", "_stext", NULL};* symbol_name if it's not that important. */ static int machine__get_running_kernel_start (struct machine *machine, -const char **symbol_name,u64 *start) +const char **symbol_name, +u64 *start,u64 *end) {char filename[PATH_MAX ];int i, err =-1 ;
@@ -949,6 +950,11 @@ static int machine__get_running_kernel_start(struct machine *machine, *symbol_name = name; *start = addr; + + err =kallsyms__get_function_start (filename,"_etext" , &addr); +if (!err) + *end = addr; +return 0 ; }
@@ -1441,7 +1447,7 @@ int machine__create_kernel_maps(struct machine *machine)struct dso *kernel =machine__get_kernel (machine);const char *name =NULL ;struct map *map; -u64 addr =0 ; +u64 start =0 , end = ~0ULL ;int ret;if (kernel ==NULL )
@@ -1460,9 +1466,9 @@ int machine__create_kernel_maps(struct machine *machine) "continuing anyway...\n", machine->pid); } -if (!machine__get_running_kernel_start (machine, &name, &addr)) { +if (!machine__get_running_kernel_start (machine, &name, &start, &end)) {if (name && -map__set_kallsyms_ref_reloc_sym (machine->vmlinux_map, name, addr)) { +map__set_kallsyms_ref_reloc_sym (machine->vmlinux_map, name, start)) {machine__destroy_kernel_maps (machine); ret =-1 ; goto out_put;
@@ -1472,16 +1478,19 @@ int machine__create_kernel_maps(struct machine *machine)* we have a real start address now, so re-order the kmaps * assume it's the last in the kmaps */ -machine__update_kernel_mmap (machine, addr, ~0ULL ); +machine__update_kernel_mmap (machine, start, end); }if (machine__create_extra_kernel_maps (machine, kernel))pr_debug ("Problems creating extra kernel maps, continuing anyway...\n" ); -/* update end address of the kernel map using adjacent module address */ - map =map__next (machine__kernel_map (machine)); -if (map) -machine__set_kernel_mmap (machine, addr, map->start); +if (end == ~0ULL ) { +/* update end address of the kernel map using adjacent module address */ + map =map__next (machine__kernel_map (machine)); +if (map) +machine__set_kernel_mmap (machine, start, map->start); + } + out_put:dso__put (kernel);return ret;
Jiri Olsa
reviewerPATCH v3 6/12 perf tools: Keep zero in pgoff bpf map
In reply to Jiri OlsaWith pgoff set to zero, the map__map_ip function
will return bpf address based from 0, which is
what we need when we read the data from bpf dso.
Adding bpf symbols with mapped ip addresses as well.
--- tools/perf/util/machine.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
tools/perf/util/machine.c +2 -2
@@ -704,12 +704,12 @@ static int machine__process_ksymbol_register(struct machine *machine,return -ENOMEM ; map->start = event->ksymbol_event.addr; - map->pgoff = map->start; map->end = map->start + event->ksymbol_event.len;map_groups__insert (&machine->kmaps, map); } - sym =symbol__new (event->ksymbol_event.addr, event->ksymbol_event.len, + sym =symbol__new (map->map_ip (map, map->start), + event->ksymbol_event.len,0 ,0 , event->ksymbol_event.name);if (!sym)return -ENOMEM ;
Signature · 1 line
2.20.1
tip-bot for Jiri Olsa
merge bot[tip:perf/core] perf machine: Keep zero in pgoff BPF map
perf machine: Keep zero in pgoff BPF map
Commit-ID: 8529f2e67313fb623da7ce81bc14cf12ccc0e12f Gitweb: https://git.kernel.org/tip/8529f2e67313fb623da7ce81bc14cf12ccc0e12f Author: Jiri Olsa <[email protected]> AuthorDate: Wed, 8 May 2019 15:20:04 +0200 Committer: Arnaldo Carvalho de Melo <[email protected]> CommitDate: Tue, 28 May 2019 18:37:42 -0300
perf machine: Keep zero in pgoff BPF map
With pgoff set to zero, the map__map_ip function will return BPF addresses based from 0, which is what we need when we read the data from a BPF DSO.
Adding BPF symbols with mapped IP addresses as well.
--- tools/perf/util/machine.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
tools/perf/util/machine.c +2 -2
@@ -704,12 +704,12 @@ static int machine__process_ksymbol_register(struct machine *machine,return -ENOMEM ; map->start = event->ksymbol_event.addr; - map->pgoff = map->start; map->end = map->start + event->ksymbol_event.len;map_groups__insert (&machine->kmaps, map); } - sym =symbol__new (event->ksymbol_event.addr, event->ksymbol_event.len, + sym =symbol__new (map->map_ip (map, map->start), + event->ksymbol_event.len,0 ,0 , event->ksymbol_event.name);if (!sym)return -ENOMEM ;
Jiri Olsa
reviewerPATCH v3 7/12 perf script: Pad dso name for --call-trace
In reply to Jiri OlsaPadding dso name for --call-trace so we don't have the indent screwed by different dso name lengths, as now for kernel there's also bpf code displayed.
# perf-with-kcore record pt -e intel_pt//ku -- sleep 1 # perf-core/perf-with-kcore script pt --call-trace
Before:
sleep 36660 [016] 1057036.806464404: ([kernel.kallsyms]) kretprobe_perf_func
sleep 36660 [016] 1057036.806464404: ([kernel.kallsyms]) trace_call_bpf
sleep 36660 [016] 1057036.806464404: ([kernel.kallsyms]) __x86_indirect_thunk_rax
sleep 36660 [016] 1057036.806464404: ([kernel.kallsyms]) __x86_indirect_thunk_rax
sleep 36660 [016] 1057036.806464725: (bpf_prog_da4fe6b3d2c29b25_trace_return) bpf_get_current_pid_tgid
sleep 36660 [016] 1057036.806464725: (bpf_prog_da4fe6b3d2c29b25_trace_return) bpf_ktime_get_ns
sleep 36660 [016] 1057036.806464725: ([kernel.kallsyms]) __x86_indirect_thunk_rax
sleep 36660 [016] 1057036.806464725: ([kernel.kallsyms]) __x86_indirect_thunk_rax
sleep 36660 [016] 1057036.806465045: (bpf_prog_da4fe6b3d2c29b25_trace_return) __htab_map_lookup_elem
sleep 36660 [016] 1057036.806465366: ([kernel.kallsyms]) memcmp
sleep 36660 [016] 1057036.806465687: (bpf_prog_da4fe6b3d2c29b25_trace_return) bpf_probe_read
sleep 36660 [016] 1057036.806465687: ([kernel.kallsyms]) probe_kernel_read
sleep 36660 [016] 1057036.806465687: ([kernel.kallsyms]) __check_object_size
sleep 36660 [016] 1057036.806465687: ([kernel.kallsyms]) check_stack_object
sleep 36660 [016] 1057036.806465687: ([kernel.kallsyms]) copy_user_enhanced_fast_string
sleep 36660 [016] 1057036.806465687: (bpf_prog_da4fe6b3d2c29b25_trace_return) bpf_probe_read
sleep 36660 [016] 1057036.806465687: ([kernel.kallsyms]) probe_kernel_read
sleep 36660 [016] 1057036.806465687: ([kernel.kallsyms]) __check_object_size
sleep 36660 [016] 1057036.806465687: ([kernel.kallsyms]) check_stack_object
sleep 36660 [016] 1057036.806465687: ([kernel.kallsyms]) copy_user_enhanced_fast_string
sleep 36660 [016] 1057036.806466008: (bpf_prog_da4fe6b3d2c29b25_trace_return) bpf_get_current_uid_gid
sleep 36660 [016] 1057036.806466008: ([kernel.kallsyms]) from_kgid
sleep 36660 [016] 1057036.806466008: ([kernel.kallsyms]) from_kuid
sleep 36660 [016] 1057036.806466008: (bpf_prog_da4fe6b3d2c29b25_trace_return) bpf_perf_event_output
sleep 36660 [016] 1057036.806466328: ([kernel.kallsyms]) perf_event_output
sleep 36660 [016] 1057036.806466328: ([kernel.kallsyms]) perf_prepare_sample
sleep 36660 [016] 1057036.806466328: ([kernel.kallsyms]) perf_misc_flags
sleep 36660 [016] 1057036.806466328: ([kernel.kallsyms]) __x86_indirect_thunk_rax
sleep 36660 [016] 1057036.806466328: ([kernel.kallsyms]) __x86_indirect_thunk_rax
sleep 36660 [016] 1057036.806466328: ([kvm]) kvm_is_in_guest
sleep 36660 [016] 1057036.806466649: ([kernel.kallsyms]) __perf_event_header__init_id.isra.0
sleep 36660 [016] 1057036.806466649: ([kernel.kallsyms]) perf_output_beginAfter:
sleep 36660 [016] 1057036.806464404: ([kernel.kallsyms] ) kretprobe_perf_func
sleep 36660 [016] 1057036.806464404: ([kernel.kallsyms] ) trace_call_bpf
sleep 36660 [016] 1057036.806464404: ([kernel.kallsyms] ) __x86_indirect_thunk_rax
sleep 36660 [016] 1057036.806464404: ([kernel.kallsyms] ) __x86_indirect_thunk_rax
sleep 36660 [016] 1057036.806464725: (bpf_prog_da4fe6b3d2c29b25_trace_return ) bpf_get_current_pid_tgid
sleep 36660 [016] 1057036.806464725: (bpf_prog_da4fe6b3d2c29b25_trace_return ) bpf_ktime_get_ns
sleep 36660 [016] 1057036.806464725: ([kernel.kallsyms] ) __x86_indirect_thunk_rax
sleep 36660 [016] 1057036.806464725: ([kernel.kallsyms] ) __x86_indirect_thunk_rax
sleep 36660 [016] 1057036.806465045: (bpf_prog_da4fe6b3d2c29b25_trace_return ) __htab_map_lookup_elem
sleep 36660 [016] 1057036.806465366: ([kernel.kallsyms] ) memcmp
sleep 36660 [016] 1057036.806465687: (bpf_prog_da4fe6b3d2c29b25_trace_return ) bpf_probe_read
sleep 36660 [016] 1057036.806465687: ([kernel.kallsyms] ) probe_kernel_read
sleep 36660 [016] 1057036.806465687: ([kernel.kallsyms] ) __check_object_size
sleep 36660 [016] 1057036.806465687: ([kernel.kallsyms] ) check_stack_object
sleep 36660 [016] 1057036.806465687: ([kernel.kallsyms] ) copy_user_enhanced_fast_string
sleep 36660 [016] 1057036.806465687: (bpf_prog_da4fe6b3d2c29b25_trace_return ) bpf_probe_read
sleep 36660 [016] 1057036.806465687: ([kernel.kallsyms] ) probe_kernel_read
sleep 36660 [016] 1057036.806465687: ([kernel.kallsyms] ) __check_object_size
sleep 36660 [016] 1057036.806465687: ([kernel.kallsyms] ) check_stack_object
sleep 36660 [016] 1057036.806465687: ([kernel.kallsyms] ) copy_user_enhanced_fast_string
sleep 36660 [016] 1057036.806466008: (bpf_prog_da4fe6b3d2c29b25_trace_return ) bpf_get_current_uid_gid
sleep 36660 [016] 1057036.806466008: ([kernel.kallsyms] ) from_kgid
sleep 36660 [016] 1057036.806466008: ([kernel.kallsyms] ) from_kuid
sleep 36660 [016] 1057036.806466008: (bpf_prog_da4fe6b3d2c29b25_trace_return ) bpf_perf_event_output
sleep 36660 [016] 1057036.806466328: ([kernel.kallsyms] ) perf_event_output
sleep 36660 [016] 1057036.806466328: ([kernel.kallsyms] ) perf_prepare_sample
sleep 36660 [016] 1057036.806466328: ([kernel.kallsyms] ) perf_misc_flags
sleep 36660 [016] 1057036.806466328: ([kernel.kallsyms] ) __x86_indirect_thunk_rax
sleep 36660 [016] 1057036.806466328: ([kernel.kallsyms] ) __x86_indirect_thunk_rax--- tools/include/linux/kernel.h | 1 + tools/lib/vsprintf.c | 19 +++++++++++++++++++ tools/perf/builtin-script.c | 1 + tools/perf/util/map.c | 6 ++++++ tools/perf/util/symbol_conf.h | 1 + 5 files changed, 28 insertions(+)
tools/include/linux/kernel.h +1 -0
@@ -102,6 +102,7 @@int vscnprintf (char *buf,size_t size,const char *fmt,va_list args);int scnprintf (char * buf,size_t size,const char * fmt, ...); +int scnprintf_pad (char * buf,size_t size,const char * fmt, ...);#define ARRAY_SIZE (arr) (sizeof(arr) / sizeof((arr)[0]) + __must_be_array(arr))
tools/lib/vsprintf.c +19 -0
@@ -23,3 +23,22 @@ int scnprintf(char * buf, size_t size, const char * fmt, ...)return (i >= ssize) ? (ssize -1 ) : i; } + +int scnprintf_pad (char * buf,size_t size,const char * fmt, ...) +{ +ssize_t ssize = size; +va_list args; +int i; + +va_start (args, fmt); + i =vscnprintf (buf, size, fmt, args); +va_end (args); + +if (i < (int ) size) { +for (; i < (int ) size; i++) + buf[i] =' ' ; + buf[i] =0x0 ; + } + +return (i >= ssize) ? (ssize -1 ) : i; +}
tools/perf/builtin-script.c +1 -0
@@ -3297,6 +3297,7 @@ static int parse_call_trace(const struct option *opt __maybe_unused,parse_output_fields (NULL ,"-ip,-addr,-event,-period,+callindent" ,0 );itrace_parse_synth_opts (opt,"cewp" ,0 ); symbol_conf.nanosecs = true; + symbol_conf.pad_output_len_dso =50 ;return 0 ; }
tools/perf/util/map.c +6 -0
@@ -405,6 +405,7 @@ size_t map__fprintf(struct map *map, FILE *fp)size_t map__fprintf_dsoname (struct map *map,FILE *fp) { +char buf[symbol_conf.pad_output_len_dso +1 ];const char *dsoname ="[unknown]" ;if (map && map->dso) {
@@ -414,6 +415,11 @@ size_t map__fprintf_dsoname(struct map *map, FILE *fp) dsoname = map->dso->name; } +if (symbol_conf.pad_output_len_dso) { +scnprintf_pad (buf, symbol_conf.pad_output_len_dso,"%s" , dsoname); + dsoname = buf; + } +return fprintf (fp,"%s" , dsoname); }
tools/perf/util/symbol_conf.h +1 -0
@@ -69,6 +69,7 @@ struct symbol_conf { *tid_list;const char *symfs;int res_sample; +int pad_output_len_dso; };extern struct symbol_conf symbol_conf;
Signature · 1 line
2.20.1
tip-bot for Jiri Olsa
merge bot[tip:perf/core] perf script: Pad DSO name for --call-trace
perf script: Pad DSO name for --call-trace
Commit-ID: 1c4924220c96392d17e0222c113509fd7b9a0854 Gitweb: https://git.kernel.org/tip/1c4924220c96392d17e0222c113509fd7b9a0854 Author: Jiri Olsa <[email protected]> AuthorDate: Wed, 8 May 2019 15:20:05 +0200 Committer: Arnaldo Carvalho de Melo <[email protected]> CommitDate: Tue, 28 May 2019 18:37:44 -0300
perf script: Pad DSO name for --call-trace
Pad the DSO name in --call-trace so we don't have the indent screwed by different DSO name lengths, as now for kernel there's also BPF code displayed.
# perf-with-kcore record pt -e intel_pt//ku -- sleep 1 # perf-core/perf-with-kcore script pt --call-trace
Before:
sleep 3660 [16] 57036.806464404: ([kernel.kallsyms]) kretprobe_perf_func
sleep 3660 [16] 57036.806464404: ([kernel.kallsyms]) trace_call_bpf
sleep 3660 [16] 57036.806464404: ([kernel.kallsyms]) __x86_indirect_thunk_rax
sleep 3660 [16] 57036.806464404: ([kernel.kallsyms]) __x86_indirect_thunk_rax
sleep 3660 [16] 57036.806464725: (bpf_prog_da4fe6b3d2c29b25_trace_return) bpf_get_current_pid_tgid
sleep 3660 [16] 57036.806464725: (bpf_prog_da4fe6b3d2c29b25_trace_return) bpf_ktime_get_ns
sleep 3660 [16] 57036.806464725: ([kernel.kallsyms]) __x86_indirect_thunk_rax
sleep 3660 [16] 57036.806464725: ([kernel.kallsyms]) __x86_indirect_thunk_rax
sleep 3660 [16] 57036.806465045: (bpf_prog_da4fe6b3d2c29b25_trace_return) __htab_map_lookup_elem
sleep 3660 [16] 57036.806465366: ([kernel.kallsyms]) memcmp
sleep 3660 [16] 57036.806465687: (bpf_prog_da4fe6b3d2c29b25_trace_return) bpf_probe_read
sleep 3660 [16] 57036.806465687: ([kernel.kallsyms]) probe_kernel_read
sleep 3660 [16] 57036.806465687: ([kernel.kallsyms]) __check_object_size
sleep 3660 [16] 57036.806465687: ([kernel.kallsyms]) check_stack_object
sleep 3660 [16] 57036.806465687: ([kernel.kallsyms]) copy_user_enhanced_fast_string
sleep 3660 [16] 57036.806465687: (bpf_prog_da4fe6b3d2c29b25_trace_return) bpf_probe_read
sleep 3660 [16] 57036.806465687: ([kernel.kallsyms]) probe_kernel_read
sleep 3660 [16] 57036.806465687: ([kernel.kallsyms]) __check_object_size
sleep 3660 [16] 57036.806465687: ([kernel.kallsyms]) check_stack_object
sleep 3660 [16] 57036.806465687: ([kernel.kallsyms]) copy_user_enhanced_fast_string
sleep 3660 [16] 57036.806466008: (bpf_prog_da4fe6b3d2c29b25_trace_return) bpf_get_current_uid_gid
sleep 3660 [16] 57036.806466008: ([kernel.kallsyms]) from_kgid
sleep 3660 [16] 57036.806466008: ([kernel.kallsyms]) from_kuid
sleep 3660 [16] 57036.806466008: (bpf_prog_da4fe6b3d2c29b25_trace_return) bpf_perf_event_output
sleep 3660 [16] 57036.806466328: ([kernel.kallsyms]) perf_event_output
sleep 3660 [16] 57036.806466328: ([kernel.kallsyms]) perf_prepare_sample
sleep 3660 [16] 57036.806466328: ([kernel.kallsyms]) perf_misc_flags
sleep 3660 [16] 57036.806466328: ([kernel.kallsyms]) __x86_indirect_thunk_rax
sleep 3660 [16] 57036.806466328: ([kernel.kallsyms]) __x86_indirect_thunk_rax
sleep 3660 [16] 57036.806466328: ([kvm]) kvm_is_in_guest
sleep 3660 [16] 57036.806466649: ([kernel.kallsyms]) __perf_event_header__init_id.isra.0
sleep 3660 [16] 57036.806466649: ([kernel.kallsyms]) perf_output_begin
After:
sleep 3660 [16] 57036.806464404: ([kernel.kallsyms] ) kretprobe_perf_func sleep 3660 [16] 57036.806464404: ([kernel.kallsyms] ) trace_call_bpf sleep 3660 [16] 57036.806464404: ([kernel.kallsyms] ) __x86_indirect_thunk_rax sleep 3660 [16] 57036.806464404: ([kernel.kallsyms] ) __x86_indirect_thunk_rax sleep 3660 [16] 57036.806464725: (bpf_prog_da4fe6b3d2c29b25_trace_return ) bpf_get_current_pid_tgid sleep 3660 [16] 57036.806464725: (bpf_prog_da4fe6b3d2c29b25_trace_return ) bpf_ktime_get_ns sleep 3660 [16] 57036.806464725: ([kernel.kallsyms] ) __x86_indirect_thunk_rax sleep 3660 [16] 57036.806464725: ([kernel.kallsyms] ) __x86_indirect_thunk_rax sleep 3660 [16] 57036.806465045: (bpf_prog_da4fe6b3d2c29b25_trace_return ) __htab_map_lookup_elem sleep 3660 [16] 57036.806465366: ([kernel.kallsyms] ) memcmp sleep 3660 [16] 57036.806465687: (bpf_prog_da4fe6b3d2c29b25_trace_return ) bpf_probe_read sleep 3660 [16] 57036.806465687: ([kernel.kallsyms] ) probe_kernel_read sleep 3660 [16] 57036.806465687: ([kernel.kallsyms] ) __check_object_size sleep 3660 [16] 57036.806465687: ([kernel.kallsyms] ) check_stack_object sleep 3660 [16] 57036.806465687: ([kernel.kallsyms] ) copy_user_enhanced_fast_string sleep 3660 [16] 57036.806465687: (bpf_prog_da4fe6b3d2c29b25_trace_return ) bpf_probe_read sleep 3660 [16] 57036.806465687: ([kernel.kallsyms] ) probe_kernel_read sleep 3660 [16] 57036.806465687: ([kernel.kallsyms] ) __check_object_size sleep 3660 [16] 57036.806465687: ([kernel.kallsyms] ) check_stack_object sleep 3660 [16] 57036.806465687: ([kernel.kallsyms] ) copy_user_enhanced_fast_string sleep 3660 [16] 57036.806466008: (bpf_prog_da4fe6b3d2c29b25_trace_return ) bpf_get_current_uid_gid sleep 3660 [16] 57036.806466008: ([kernel.kallsyms] ) from_kgid sleep 3660 [16] 57036.806466008: ([kernel.kallsyms] ) from_kuid sleep 3660 [16] 57036.806466008: (bpf_prog_da4fe6b3d2c29b25_trace_return ) bpf_perf_event_output sleep 3660 [16] 57036.806466328: ([kernel.kallsyms] ) perf_event_output sleep 3660 [16] 57036.806466328: ([kernel.kallsyms] ) perf_prepare_sample sleep 3660 [16] 57036.806466328: ([kernel.kallsyms] ) perf_misc_flags sleep 3660 [16] 57036.806466328: ([kernel.kallsyms] ) __x86_indirect_thunk_rax sleep 3660 [16] 57036.806466328: ([kernel.kallsyms] ) __x86_indirect_thunk_rax
--- tools/include/linux/kernel.h | 1 + tools/lib/vsprintf.c | 19 +++++++++++++++++++ tools/perf/builtin-script.c | 1 + tools/perf/util/map.c | 6 ++++++ tools/perf/util/symbol_conf.h | 1 + 5 files changed, 28 insertions(+)
tools/include/linux/kernel.h +1 -0
@@ -102,6 +102,7 @@int vscnprintf (char *buf,size_t size,const char *fmt,va_list args);int scnprintf (char * buf,size_t size,const char * fmt, ...); +int scnprintf_pad (char * buf,size_t size,const char * fmt, ...);#define ARRAY_SIZE (arr) (sizeof(arr) / sizeof((arr)[0]) + __must_be_array(arr))
tools/lib/vsprintf.c +19 -0
@@ -23,3 +23,22 @@ int scnprintf(char * buf, size_t size, const char * fmt, ...)return (i >= ssize) ? (ssize -1 ) : i; } + +int scnprintf_pad (char * buf,size_t size,const char * fmt, ...) +{ +ssize_t ssize = size; +va_list args; +int i; + +va_start (args, fmt); + i =vscnprintf (buf, size, fmt, args); +va_end (args); + +if (i < (int ) size) { +for (; i < (int ) size; i++) + buf[i] =' ' ; + buf[i] =0x0 ; + } + +return (i >= ssize) ? (ssize -1 ) : i; +}
tools/perf/builtin-script.c +1 -0
@@ -3297,6 +3297,7 @@ static int parse_call_trace(const struct option *opt __maybe_unused,parse_output_fields (NULL ,"-ip,-addr,-event,-period,+callindent" ,0 );itrace_parse_synth_opts (opt,"cewp" ,0 ); symbol_conf.nanosecs = true; + symbol_conf.pad_output_len_dso =50 ;return 0 ; }
tools/perf/util/map.c +6 -0
@@ -405,6 +405,7 @@ size_t map__fprintf(struct map *map, FILE *fp)size_t map__fprintf_dsoname (struct map *map,FILE *fp) { +char buf[symbol_conf.pad_output_len_dso +1 ];const char *dsoname ="[unknown]" ;if (map && map->dso) {
@@ -414,6 +415,11 @@ size_t map__fprintf_dsoname(struct map *map, FILE *fp) dsoname = map->dso->name; } +if (symbol_conf.pad_output_len_dso) { +scnprintf_pad (buf, symbol_conf.pad_output_len_dso,"%s" , dsoname); + dsoname = buf; + } +return fprintf (fp,"%s" , dsoname); }
tools/perf/util/symbol_conf.h +1 -0
@@ -69,6 +69,7 @@ struct symbol_conf { *tid_list;const char *symfs;int res_sample; +int pad_output_len_dso; };extern struct symbol_conf symbol_conf;
Jiri Olsa
reviewerPATCH v3 8/12 perf tools: Preserve eBPF maps when loading kcore
In reply to Jiri OlsaWe need to preserve eBPF maps even if they are covered by kcore, because we need to access eBPF dso for source data.
Adding map_groups__merge_in function to do that. It merges map into map_groups by splitting the new map within the existing map regions.
--- tools/perf/util/symbol.c | 97 ++++++++++++++++++++++++++++++++++++++-- 1 file changed, 93 insertions(+), 4 deletions(-)
tools/perf/util/symbol.c +93 -4
@@ -1166,6 +1166,85 @@ static int kcore_mapfn(u64 start, u64 len, u64 pgoff, void *data)return 0 ; } +/* +* Merges map into map_groups by splitting the new map +* within the existing map regions. +*/ +static int map_groups__merge_in (struct map_groups *kmaps,struct map *new_map) +{ +struct map *old_map; +LIST_HEAD (merged); + +for (old_map =map_groups__first (kmaps); old_map; + old_map =map_groups__next (old_map)) { + +/* no overload with this one */ +if (new_map->end < old_map->start || + new_map->start >= old_map->end) +continue ; + +if (new_map->start < old_map->start) { +/* +* |new...... +* |old.... +*/ +if (new_map->end < old_map->end) { +/* +* |new......| -> |new..| +* |old....| -> |old....| +*/ + new_map->end = old_map->start; + }else { +/* +* |new.............| -> |new..| |new..| +* |old....| -> |old....| +*/ +struct map *m =map__clone (new_map); + +if (!m) +return -ENOMEM ; + + m->end = old_map->start; +list_add_tail (&m->node, &merged); + new_map->start = old_map->end; + } + }else { +/* +* |new...... +* |old.... +*/ +if (new_map->end < old_map->end) { +/* +* |new..| -> x +* |old.........| -> |old.........| +*/ +map__put (new_map); + new_map =NULL ; +break ; + }else { +/* +* |new......| -> |new...| +* |old....| -> |old....| +*/ + new_map->start = old_map->end; + } + } + } + +while (!list_empty (&merged)) { + old_map = list_entry(merged.next, struct map, node); +list_del_init (&old_map->node); +map_groups__insert (kmaps, old_map); +map__put (old_map); + } + +if (new_map) { +map_groups__insert (kmaps, new_map); +map__put (new_map); + } +return 0 ; +} +static int dso__load_kcore (struct dso *dso,struct map *map,const char *kallsyms_filename) {
@@ -1222,7 +1301,12 @@ static int dso__load_kcore(struct dso *dso, struct map *map,while (old_map) {struct map *next =map_groups__next (old_map); -if (old_map != map) +/* +* We need to preserve eBPF maps even if they are +* covered by kcore, because we need to access +* eBPF dso for source data. +*/ +if (old_map != map && !__map__is_bpf_prog (old_map))map_groups__remove (kmaps, old_map); old_map = next; }
@@ -1256,11 +1340,16 @@ static int dso__load_kcore(struct dso *dso, struct map *map,map_groups__remove (kmaps, map);map_groups__insert (kmaps, map);map__put (map); +map__put (new_map); }else { -map_groups__insert (kmaps, new_map); +/* +* Merge kcore map into existing maps, +* and ensure that current maps (eBPF) +* stay intact. +*/ +if (map_groups__merge_in (kmaps, new_map)) + goto out_err; } - -map__put (new_map); }if (machine__is (machine,"x86_64" )) {
Signature · 1 line
2.20.1
Re: [PATCH 08/12] perf tools: Preserve eBPF maps when loading kcore
Em Wed, May 08, 2019 at 03:20:06PM +0200, Jiri Olsa escreveu:
Quoted 3 lines
We need to preserve eBPF maps even if they are covered by kcore, because we need to access eBPF dso for source data.
So, I reordered this one with the previous, as to get the output you added to 07/12 we need what is in 08/12, and they are otherwise completely independent, right?
- Arnaldo
Quoted 137 lines
Adding
map_groups__merge_infunction to do that. It merges map intomap_groupsby splitting the new map within the existing map regions.Suggested-by Adrian Hunter <[email protected]>Signed-off-by Jiri Olsa <[email protected]>--- tools/perf/util/symbol.c | 97 ++++++++++++++++++++++++++++++++++++++-- 1 file changed, 93 insertions(+), 4 deletions(-)tools/perf/util/symbol.c +93
-4@@ -1166,6 +1166,85 @@ static int kcore_mapfn(u64 start, u64 len, u64 pgoff, void *data)return 0 ; } +/* +* Merges map into map_groups by splitting the new map +* within the existing map regions. +*/ +static int map_groups__merge_in (struct map_groups *kmaps,struct map *new_map) +{ +struct map *old_map; +LIST_HEAD (merged); + +for (old_map =map_groups__first (kmaps); old_map; + old_map =map_groups__next (old_map)) { + +/* no overload with this one */ +if (new_map->end < old_map->start || + new_map->start >= old_map->end) +continue ; + +if (new_map->start < old_map->start) { +/* +* |new...... +* |old.... +*/ +if (new_map->end < old_map->end) { +/* +* |new......| -> |new..| +* |old....| -> |old....| +*/ + new_map->end = old_map->start; + }else { +/* +* |new.............| -> |new..| |new..| +* |old....| -> |old....| +*/ +struct map *m =map__clone (new_map); + +if (!m) +return -ENOMEM ; + + m->end = old_map->start; +list_add_tail (&m->node, &merged); + new_map->start = old_map->end; + } + }else { +/* +* |new...... +* |old.... +*/ +if (new_map->end < old_map->end) { +/* +* |new..| -> x +* |old.........| -> |old.........| +*/ +map__put (new_map); + new_map =NULL ; +break ; + }else { +/* +* |new......| -> |new...| +* |old....| -> |old....| +*/ + new_map->start = old_map->end; + } + } + } + +while (!list_empty (&merged)) { + old_map = list_entry(merged.next, struct map, node); +list_del_init (&old_map->node); +map_groups__insert (kmaps, old_map); +map__put (old_map); + } + +if (new_map) { +map_groups__insert (kmaps, new_map); +map__put (new_map); + } +return 0 ; +} +static int dso__load_kcore (struct dso *dso,struct map *map,const char *kallsyms_filename) {@@ -1222,7 +1301,12 @@ static int dso__load_kcore(struct dso *dso, struct map *map,while (old_map) {struct map *next =map_groups__next (old_map); -if (old_map != map) +/* +* We need to preserve eBPF maps even if they are +* covered by kcore, because we need to access +* eBPF dso for source data. +*/ +if (old_map != map && !__map__is_bpf_prog (old_map))map_groups__remove (kmaps, old_map); old_map = next; }@@ -1256,11 +1340,16 @@ static int dso__load_kcore(struct dso *dso, struct map *map,map_groups__remove (kmaps, map);map_groups__insert (kmaps, map);map__put (map); +map__put (new_map); }else { -map_groups__insert (kmaps, new_map); +/* +* Merge kcore map into existing maps, +* and ensure that current maps (eBPF) +* stay intact. +*/ +if (map_groups__merge_in (kmaps, new_map)) + goto out_err; } - -map__put (new_map); }if (machine__is (machine,"x86_64" )) {Signature · 1 line
2.20.1
Signature · 1 line
- Arnaldo
Re: [PATCH 08/12] perf tools: Preserve eBPF maps when loading kcore
Quoted 8 lines · Arnaldo Carvalho de Melo
Em Wed, May 08, 2019 at 03:20:06PM +0200, Jiri Olsa escreveu:
Quoted 3 lines
We need to preserve eBPF maps even if they are covered by kcore, because we need to access eBPF dso for source data.
So, I reordered this one with the previous, as to get the output you added to 07/12 we need what is in 08/12, and they are otherwise completely independent, right?
right
jirka
Quoted 144 lines
- Arnaldo
Quoted 137 lines
Adding
map_groups__merge_infunction to do that. It merges map intomap_groupsby splitting the new map within the existing map regions.Suggested-by Adrian Hunter <[email protected]>Signed-off-by Jiri Olsa <[email protected]>--- tools/perf/util/symbol.c | 97 ++++++++++++++++++++++++++++++++++++++-- 1 file changed, 93 insertions(+), 4 deletions(-)tools/perf/util/symbol.c +93
-4@@ -1166,6 +1166,85 @@ static int kcore_mapfn(u64 start, u64 len, u64 pgoff, void *data)return 0 ; } +/* +* Merges map into map_groups by splitting the new map +* within the existing map regions. +*/ +static int map_groups__merge_in (struct map_groups *kmaps,struct map *new_map) +{ +struct map *old_map; +LIST_HEAD (merged); + +for (old_map =map_groups__first (kmaps); old_map; + old_map =map_groups__next (old_map)) { + +/* no overload with this one */ +if (new_map->end < old_map->start || + new_map->start >= old_map->end) +continue ; + +if (new_map->start < old_map->start) { +/* +* |new...... +* |old.... +*/ +if (new_map->end < old_map->end) { +/* +* |new......| -> |new..| +* |old....| -> |old....| +*/ + new_map->end = old_map->start; + }else { +/* +* |new.............| -> |new..| |new..| +* |old....| -> |old....| +*/ +struct map *m =map__clone (new_map); + +if (!m) +return -ENOMEM ; + + m->end = old_map->start; +list_add_tail (&m->node, &merged); + new_map->start = old_map->end; + } + }else { +/* +* |new...... +* |old.... +*/ +if (new_map->end < old_map->end) { +/* +* |new..| -> x +* |old.........| -> |old.........| +*/ +map__put (new_map); + new_map =NULL ; +break ; + }else { +/* +* |new......| -> |new...| +* |old....| -> |old....| +*/ + new_map->start = old_map->end; + } + } + } + +while (!list_empty (&merged)) { + old_map = list_entry(merged.next, struct map, node); +list_del_init (&old_map->node); +map_groups__insert (kmaps, old_map); +map__put (old_map); + } + +if (new_map) { +map_groups__insert (kmaps, new_map); +map__put (new_map); + } +return 0 ; +} +static int dso__load_kcore (struct dso *dso,struct map *map,const char *kallsyms_filename) {@@ -1222,7 +1301,12 @@ static int dso__load_kcore(struct dso *dso, struct map *map,while (old_map) {struct map *next =map_groups__next (old_map); -if (old_map != map) +/* +* We need to preserve eBPF maps even if they are +* covered by kcore, because we need to access +* eBPF dso for source data. +*/ +if (old_map != map && !__map__is_bpf_prog (old_map))map_groups__remove (kmaps, old_map); old_map = next; }@@ -1256,11 +1340,16 @@ static int dso__load_kcore(struct dso *dso, struct map *map,map_groups__remove (kmaps, map);map_groups__insert (kmaps, map);map__put (map); +map__put (new_map); }else { -map_groups__insert (kmaps, new_map); +/* +* Merge kcore map into existing maps, +* and ensure that current maps (eBPF) +* stay intact. +*/ +if (map_groups__merge_in (kmaps, new_map)) + goto out_err; } - -map__put (new_map); }if (machine__is (machine,"x86_64" )) {Signature · 1 line
2.20.1Signature · 1 line
- Arnaldo
tip-bot for Jiri Olsa
merge bot[tip:perf/core] perf tools: Preserve eBPF maps when loading kcore
In reply to Jiri Olsaperf tools: Preserve eBPF maps when loading kcore
Commit-ID: fb5a88d4131a9ee8bec3f4bb7c034d7a4e9cf5ea Gitweb: https://git.kernel.org/tip/fb5a88d4131a9ee8bec3f4bb7c034d7a4e9cf5ea Author: Jiri Olsa <[email protected]> AuthorDate: Wed, 8 May 2019 15:20:06 +0200 Committer: Arnaldo Carvalho de Melo <[email protected]> CommitDate: Tue, 28 May 2019 18:37:42 -0300
perf tools: Preserve eBPF maps when loading kcore
We need to preserve eBPF maps even if they are covered by kcore, because we need to access eBPF dso for source data.
Add the map_groups__merge_in function to do that. It merges a map into map_groups by splitting the new map within the existing map regions.
--- tools/perf/util/symbol.c | 97 ++++++++++++++++++++++++++++++++++++++++++++++-- 1 file changed, 93 insertions(+), 4 deletions(-)
tools/perf/util/symbol.c +93 -4
@@ -1166,6 +1166,85 @@ static int kcore_mapfn(u64 start, u64 len, u64 pgoff, void *data)return 0 ; } +/* +* Merges map into map_groups by splitting the new map +* within the existing map regions. +*/ +static int map_groups__merge_in (struct map_groups *kmaps,struct map *new_map) +{ +struct map *old_map; +LIST_HEAD (merged); + +for (old_map =map_groups__first (kmaps); old_map; + old_map =map_groups__next (old_map)) { + +/* no overload with this one */ +if (new_map->end < old_map->start || + new_map->start >= old_map->end) +continue ; + +if (new_map->start < old_map->start) { +/* +* |new...... +* |old.... +*/ +if (new_map->end < old_map->end) { +/* +* |new......| -> |new..| +* |old....| -> |old....| +*/ + new_map->end = old_map->start; + }else { +/* +* |new.............| -> |new..| |new..| +* |old....| -> |old....| +*/ +struct map *m =map__clone (new_map); + +if (!m) +return -ENOMEM ; + + m->end = old_map->start; +list_add_tail (&m->node, &merged); + new_map->start = old_map->end; + } + }else { +/* +* |new...... +* |old.... +*/ +if (new_map->end < old_map->end) { +/* +* |new..| -> x +* |old.........| -> |old.........| +*/ +map__put (new_map); + new_map =NULL ; +break ; + }else { +/* +* |new......| -> |new...| +* |old....| -> |old....| +*/ + new_map->start = old_map->end; + } + } + } + +while (!list_empty (&merged)) { + old_map = list_entry(merged.next, struct map, node); +list_del_init (&old_map->node); +map_groups__insert (kmaps, old_map); +map__put (old_map); + } + +if (new_map) { +map_groups__insert (kmaps, new_map); +map__put (new_map); + } +return 0 ; +} +static int dso__load_kcore (struct dso *dso,struct map *map,const char *kallsyms_filename) {
@@ -1222,7 +1301,12 @@ static int dso__load_kcore(struct dso *dso, struct map *map,while (old_map) {struct map *next =map_groups__next (old_map); -if (old_map != map) +/* +* We need to preserve eBPF maps even if they are +* covered by kcore, because we need to access +* eBPF dso for source data. +*/ +if (old_map != map && !__map__is_bpf_prog (old_map))map_groups__remove (kmaps, old_map); old_map = next; }
@@ -1256,11 +1340,16 @@ static int dso__load_kcore(struct dso *dso, struct map *map,map_groups__remove (kmaps, map);map_groups__insert (kmaps, map);map__put (map); +map__put (new_map); }else { -map_groups__insert (kmaps, new_map); +/* +* Merge kcore map into existing maps, +* and ensure that current maps (eBPF) +* stay intact. +*/ +if (map_groups__merge_in (kmaps, new_map)) + goto out_err; } - -map__put (new_map); }if (machine__is (machine,"x86_64" )) {
Jiri Olsa
reviewerPATCH v3 9/12 perf tests: Add map_groups__merge_in test
In reply to Jiri OlsaAdding map_groups__merge_in to test map_groups__merge_in function usage - merging kcore maps into existing eBPF maps.
--- tools/perf/tests/Build | 1 + tools/perf/tests/builtin-test.c | 4 ++ tools/perf/tests/map_groups.c | 120 ++++++++++++++++++++++++++++++++ tools/perf/tests/tests.h | 1 + tools/perf/util/map_groups.h | 2 + tools/perf/util/symbol.c | 2 +- 6 files changed, 129 insertions(+), 1 deletion(-) create mode 100644 tools/perf/tests/map_groups.c
tools/perf/tests/Build +1 -0
@@ -50,6 +50,7 @@ perf-y += perf-hooks.o perf-y += clang.o perf-y += unit_number__scnprintf.o perf-y += mem2node.o +perf-y += map_groups.o $(OUTPUT)tests/llvm-src-base.c: tests/bpf-script-example.c tests/Build $(call rule_mkdir)
tools/perf/tests/builtin-test.c +4 -0
@@ -289,6 +289,10 @@ static struct test generic_tests[] = { .desc = "mem2node", .func = test__mem2node, }, + { + .desc = "map_groups__merge_in", + .func = test__map_groups__merge_in, + }, { .func = NULL, },
tools/perf/tests/map_groups.c new file +120 -0
120 lines not on this page · raw message
tools/perf/tests/tests.h +1 -0
@@ -107,6 +107,7 @@ const char *test__clang_subtest_get_desc(int subtest);int test__clang_subtest_get_nr (void );int test__unit_number__scnprint (struct test *test,int subtest);int test__mem2node (struct test *t,int subtest); +int test__map_groups__merge_in (struct test *t,int subtest);bool test__bp_signal_is_supported (void );bool test__wp_is_supported (void );
tools/perf/util/map_groups.h +2 -0
@@ -88,4 +88,6 @@ int map_groups__fixup_overlappings(struct map_groups *mg, struct map *map, FILEstruct map *map_groups__find_by_name (struct map_groups *mg,const char *name); +int map_groups__merge_in (struct map_groups *kmaps,struct map *new_map); +#endif // __PERF_MAP_GROUPS_H
tools/perf/util/symbol.c +1 -1
@@ -1170,7 +1170,7 @@ static int kcore_mapfn(u64 start, u64 len, u64 pgoff, void *data)* Merges map into map_groups by splitting the new map * within the existing map regions. */ -static int map_groups__merge_in (struct map_groups *kmaps,struct map *new_map) +int map_groups__merge_in (struct map_groups *kmaps,struct map *new_map) {struct map *old_map;LIST_HEAD (merged);
Signature · 1 line
2.20.1
tip-bot for Jiri Olsa
merge bot[tip:perf/core] perf tests: Add map_groups__merge_in test
perf tests: Add map_groups__merge_in test
Commit-ID: 4f600bcf657d4d0476d0d96cb38077a72b8fb2af Gitweb: https://git.kernel.org/tip/4f600bcf657d4d0476d0d96cb38077a72b8fb2af Author: Jiri Olsa <[email protected]> AuthorDate: Wed, 8 May 2019 15:20:07 +0200 Committer: Arnaldo Carvalho de Melo <[email protected]> CommitDate: Tue, 28 May 2019 18:37:44 -0300
perf tests: Add map_groups__merge_in test
Add map_groups__merge_in test to test the map_groups__merge_in function usage - merging kcore maps into existing eBPF maps.
Committer testing:
# perf test merge 59: map_groups__merge_in : Ok # perf test -v merge 59: map_groups__merge_in : --- start --- test child forked, pid 8349 test child finished with 0 ---- end ---- map_groups__merge_in: Ok #
--- tools/perf/tests/Build | 1 + tools/perf/tests/builtin-test.c | 4 ++ tools/perf/tests/map_groups.c | 120 ++++++++++++++++++++++++++++++++++++++++ tools/perf/tests/tests.h | 1 + tools/perf/util/map_groups.h | 2 + tools/perf/util/symbol.c | 2 +- 6 files changed, 129 insertions(+), 1 deletion(-)
tools/perf/tests/Build +1 -0
@@ -50,6 +50,7 @@ perf-y += perf-hooks.o perf-y += clang.o perf-y += unit_number__scnprintf.o perf-y += mem2node.o +perf-y += map_groups.o $(OUTPUT)tests/llvm-src-base.c: tests/bpf-script-example.c tests/Build $(call rule_mkdir)
tools/perf/tests/builtin-test.c +4 -0
@@ -289,6 +289,10 @@ static struct test generic_tests[] = { .desc = "mem2node", .func = test__mem2node, }, + { + .desc = "map_groups__merge_in", + .func = test__map_groups__merge_in, + }, { .func = NULL, },
tools/perf/tests/map_groups.c new file +120 -0
120 lines not on this page · raw message
tools/perf/tests/tests.h +1 -0
@@ -107,6 +107,7 @@ const char *test__clang_subtest_get_desc(int subtest);int test__clang_subtest_get_nr (void );int test__unit_number__scnprint (struct test *test,int subtest);int test__mem2node (struct test *t,int subtest); +int test__map_groups__merge_in (struct test *t,int subtest);bool test__bp_signal_is_supported (void );bool test__wp_is_supported (void );
tools/perf/util/map_groups.h +2 -0
@@ -88,4 +88,6 @@ int map_groups__fixup_overlappings(struct map_groups *mg, struct map *map, FILEstruct map *map_groups__find_by_name (struct map_groups *mg,const char *name); +int map_groups__merge_in (struct map_groups *kmaps,struct map *new_map); +#endif // __PERF_MAP_GROUPS_H
tools/perf/util/symbol.c +1 -1
@@ -1170,7 +1170,7 @@ static int kcore_mapfn(u64 start, u64 len, u64 pgoff, void *data)* Merges map into map_groups by splitting the new map * within the existing map regions. */ -static int map_groups__merge_in (struct map_groups *kmaps,struct map *new_map) +int map_groups__merge_in (struct map_groups *kmaps,struct map *new_map) {struct map *old_map;LIST_HEAD (merged);
Jiri Olsa
reviewerPATCH v3 10/12 perf script: Add --show-bpf-events to show eBPF related events
In reply to Jiri OlsaAdding --show-bpf-events to show eBPF related events:
PERF_RECORD_KSYMBOL
PERF_RECORD_BPF_EVENT
Usage:
# perf record -a ... # perf script --show-bpf-events ... swapper 0 [000] 0.000000: PERF_RECORD_KSYMBOL ksymbol event with addr ffffffffc0ef971d len 229 type 1 flags 0x0 name bpf_prog_2a142ef67aaad174 swapper 0 [000] 0.000000: PERF_RECORD_BPF_EVENT bpf event with type 1, flags 0, id 36 ...
--- tools/perf/Documentation/perf-script.txt | 3 ++ tools/perf/builtin-script.c | 42 ++++++++++++++++++++++++ 2 files changed, 45 insertions(+)
tools/perf/Documentation/perf-script.txt +3 -0
@@ -313,6 +313,9 @@ OPTIONS --show-round-events Display finished round events i.e. events of type PERF_RECORD_FINISHED_ROUND. +--show-bpf-events + Display bpf events i.e. events of type PERF_RECORD_KSYMBOL and PERF_RECORD_BPF_EVENT. + --demangle:: Demangle symbol names to human readable form. It's enabled by default, disable with --no-demangle.
tools/perf/builtin-script.c +42 -0
66 lines not on this page · raw message
Signature · 1 line
2.20.1
tip-bot for Jiri Olsa
merge bot[tip:perf/core] perf script: Add --show-bpf-events to show eBPF related events
perf script: Add --show-bpf-events to show eBPF related events
Commit-ID: 490c8cc949eca14bfdbee0ad1cd1c6d3ddf46b77 Gitweb: https://git.kernel.org/tip/490c8cc949eca14bfdbee0ad1cd1c6d3ddf46b77 Author: Jiri Olsa <[email protected]> AuthorDate: Wed, 8 May 2019 15:20:08 +0200 Committer: Arnaldo Carvalho de Melo <[email protected]> CommitDate: Tue, 28 May 2019 18:37:44 -0300
perf script: Add --show-bpf-events to show eBPF related events
Add the --show-bpf-events command line option to show the eBPF related events:
PERF_RECORD_KSYMBOL
PERF_RECORD_BPF_EVENT
Usage:
# perf record -a ... # perf script --show-bpf-events ... swapper 0 [000] 0.000000: PERF_RECORD_KSYMBOL ksymbol event with addr ffffffffc0ef971d len 229 type 1 flags 0x0 name bpf_prog_2a142ef67aaad174 swapper 0 [000] 0.000000: PERF_RECORD_BPF_EVENT bpf event with type 1, flags 0, id 36 ...
Committer testing:
# perf script --show-bpf-events | egrep -i 'PERF_RECORD_(BPF|KSY)'
0 PERF_RECORD_KSYMBOL ksymbol event with addr ffffffffc029a6c3 len 229 type 1 flags 0x0 name bpf_prog_7be49e3934a125ba
0 PERF_RECORD_BPF_EVENT bpf event with type 1, flags 0, id 47
0 PERF_RECORD_KSYMBOL ksymbol event with addr ffffffffc029c1ae len 229 type 1 flags 0x0 name bpf_prog_2a142ef67aaad174
0 PERF_RECORD_BPF_EVENT bpf event with type 1, flags 0, id 48
0 PERF_RECORD_KSYMBOL ksymbol event with addr ffffffffc02ddd1c len 229 type 1 flags 0x0 name bpf_prog_7be49e3934a125ba
0 PERF_RECORD_BPF_EVENT bpf event with type 1, flags 0, id 49
0 PERF_RECORD_KSYMBOL ksymbol event with addr ffffffffc02dfc11 len 229 type 1 flags 0x0 name bpf_prog_2a142ef67aaad174
0 PERF_RECORD_BPF_EVENT bpf event with type 1, flags 0, id 50
0 PERF_RECORD_KSYMBOL ksymbol event with addr ffffffffc045da0a len 229 type 1 flags 0x0 name bpf_prog_7be49e3934a125ba
0 PERF_RECORD_BPF_EVENT bpf event with type 1, flags 0, id 51
0 PERF_RECORD_KSYMBOL ksymbol event with addr ffffffffc04ef4b4 len 229 type 1 flags 0x0 name bpf_prog_2a142ef67aaad174
0 PERF_RECORD_BPF_EVENT bpf event with type 1, flags 0, id 52
0 PERF_RECORD_KSYMBOL ksymbol event with addr ffffffffc09e15da len 229 type 1 flags 0x0 name bpf_prog_7be49e3934a125ba
0 PERF_RECORD_BPF_EVENT bpf event with type 1, flags 0, id 53
0 PERF_RECORD_KSYMBOL ksymbol event with addr ffffffffc0d2b1a3 len 229 type 1 flags 0x0 name bpf_prog_2a142ef67aaad174
0 PERF_RECORD_BPF_EVENT bpf event with type 1, flags 0, id 54
0 PERF_RECORD_KSYMBOL ksymbol event with addr ffffffffc0fd9850 len 381 type 1 flags 0x0 name bpf_prog_819967866022f1e1_sys_enter
0 PERF_RECORD_BPF_EVENT bpf event with type 1, flags 0, id 179
0 PERF_RECORD_KSYMBOL ksymbol event with addr ffffffffc0feb1ec len 191 type 1 flags 0x0 name bpf_prog_c1bd85c092d6e4aa_sys_exit
0 PERF_RECORD_BPF_EVENT bpf event with type 1, flags 0, id 180
^C[root@quaco pt]# perf evlist
intel_pt//ku
dummy:u
#--- tools/perf/Documentation/perf-script.txt | 3 +++ tools/perf/builtin-script.c | 42 ++++++++++++++++++++++++++++++++ 2 files changed, 45 insertions(+)
tools/perf/Documentation/perf-script.txt +3 -0
@@ -313,6 +313,9 @@ OPTIONS --show-round-events Display finished round events i.e. events of type PERF_RECORD_FINISHED_ROUND. +--show-bpf-events + Display bpf events i.e. events of type PERF_RECORD_KSYMBOL and PERF_RECORD_BPF_EVENT. + --demangle:: Demangle symbol names to human readable form. It's enabled by default, disable with --no-demangle.
tools/perf/builtin-script.c +42 -0
66 lines not on this page · raw message
Jiri Olsa
reviewerPATCH v3 11/12 perf script: Remove superfluous bpf event titles
In reply to Jiri OlsaThere's no need to display "ksymbol event with" text for PERF_RECORD_KSYMBOL event and "bpf event with" test for PERF_RECORD_BPF_EVENT event.
Removing it so it also goes along with other side-band events display.
Before:
# perf script --show-bpf-events ... swapper 0 [000] 0.000000: PERF_RECORD_KSYMBOL ksymbol event with addr ffffffffc0ef971d len 229 type 1 flags 0x0 name bpf_prog_2a142ef67aaad174 swapper 0 [000] 0.000000: PERF_RECORD_BPF_EVENT bpf event with type 1, flags 0, id 36
After:
# perf script --show-bpf-events ... swapper 0 [000] 0.000000: PERF_RECORD_KSYMBOL addr ffffffffc0ef971d len 229 type 1 flags 0x0 name bpf_prog_2a142ef67aaad174 swapper 0 [000] 0.000000: PERF_RECORD_BPF_EVENT type 1, flags 0, id 36
--- tools/perf/util/event.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
tools/perf/util/event.c +2 -2
@@ -1485,7 +1485,7 @@ static size_t perf_event__fprintf_lost(union perf_event *event, FILE *fp)size_t perf_event__fprintf_ksymbol (union perf_event *event,FILE *fp) { -return fprintf (fp," ksymbol event with addr %" PRIx64" len %u type %u flags 0x%x name %s\n" , +return fprintf (fp," addr %" PRIx64" len %u type %u flags 0x%x name %s\n" , event->ksymbol_event.addr, event->ksymbol_event.len, event->ksymbol_event.ksym_type, event->ksymbol_event.flags, event->ksymbol_event.name);
@@ -1493,7 +1493,7 @@ size_t perf_event__fprintf_ksymbol(union perf_event *event, FILE *fp)size_t perf_event__fprintf_bpf_event (union perf_event *event,FILE *fp) { -return fprintf (fp," bpf event with type %u, flags %u, id %u\n" , +return fprintf (fp," type %u, flags %u, id %u\n" , event->bpf_event.type, event->bpf_event.flags, event->bpf_event.id); }
Signature · 1 line
2.20.1
tip-bot for Jiri Olsa
merge bot[tip:perf/core] perf script: Remove superfluous BPF event titles
perf script: Remove superfluous BPF event titles
Commit-ID: 8201787cbb723a20bf262ecb41b74962ad27e659 Gitweb: https://git.kernel.org/tip/8201787cbb723a20bf262ecb41b74962ad27e659 Author: Jiri Olsa <[email protected]> AuthorDate: Wed, 8 May 2019 15:20:09 +0200 Committer: Arnaldo Carvalho de Melo <[email protected]> CommitDate: Tue, 28 May 2019 18:37:44 -0300
perf script: Remove superfluous BPF event titles
There's no need to display "ksymbol event with" text for the PERF_RECORD_KSYMBOL event and "bpf event with" test for the PERF_RECORD_BPF_EVENT event.
Remove it so it also goes along with other side-band events display.
Before:
# perf script --show-bpf-events ... swapper 0 [000] 0.000000: PERF_RECORD_KSYMBOL ksymbol event with addr ffffffffc0ef971d len 229 type 1 flags 0x0 name bpf_prog_2a142ef67aaad174 swapper 0 [000] 0.000000: PERF_RECORD_BPF_EVENT bpf event with type 1, flags 0, id 36
After:
# perf script --show-bpf-events ... swapper 0 [000] 0.000000: PERF_RECORD_KSYMBOL addr ffffffffc0ef971d len 229 type 1 flags 0x0 name bpf_prog_2a142ef67aaad174 swapper 0 [000] 0.000000: PERF_RECORD_BPF_EVENT type 1, flags 0, id 36
--- tools/perf/util/event.c | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-)
tools/perf/util/event.c +2 -2
@@ -1486,7 +1486,7 @@ static size_t perf_event__fprintf_lost(union perf_event *event, FILE *fp)size_t perf_event__fprintf_ksymbol (union perf_event *event,FILE *fp) { -return fprintf (fp," ksymbol event with addr %" PRIx64" len %u type %u flags 0x%x name %s\n" , +return fprintf (fp," addr %" PRIx64" len %u type %u flags 0x%x name %s\n" , event->ksymbol_event.addr, event->ksymbol_event.len, event->ksymbol_event.ksym_type, event->ksymbol_event.flags, event->ksymbol_event.name);
@@ -1494,7 +1494,7 @@ size_t perf_event__fprintf_ksymbol(union perf_event *event, FILE *fp)size_t perf_event__fprintf_bpf_event (union perf_event *event,FILE *fp) { -return fprintf (fp," bpf event with type %u, flags %u, id %u\n" , +return fprintf (fp," type %u, flags %u, id %u\n" , event->bpf_event.type, event->bpf_event.flags, event->bpf_event.id); }
Jiri Olsa
reviewerPATCH v3 12/12 perf script: Add --show-all-events option
In reply to Jiri OlsaAdding --show-all-events option to show all
side-bad events with single option, like:
$ perf script --show-all-events swapper 0 [000] 0.000000: PERF_RECORD_MMAP -1/0: [0xffffffffa6000000(0xc00e41) @ 0xffffffffa6000000]: x [kernel.kallsyms]_text ... swapper 0 [000] 0.000000: PERF_RECORD_KSYMBOL addr ffffffffc01bc362 len 229 type 1 flags 0x0 name bpf_prog_7be49e3934a125ba swapper 0 [000] 0.000000: PERF_RECORD_BPF_EVENT type 1, flags 0, id 29 ... swapper 0 [000] 0.000000: PERF_RECORD_FORK(1:1):(0:0) systemd 0 [000] 0.000000: PERF_RECORD_COMM: systemd:1/1 ... swapper 0 [000] 63587.039518: 1 cycles: ffffffffa60698b4 [unknown] ([kernel.kallsyms]) swapper 0 [000] 63587.039522: 1 cycles: ffffffffa60698b4 [unknown] ([kernel.kallsyms])
--- tools/perf/Documentation/perf-script.txt | 3 +++ tools/perf/builtin-script.c | 13 +++++++++++++ 2 files changed, 16 insertions(+)
tools/perf/Documentation/perf-script.txt +3 -0
@@ -316,6 +316,9 @@ OPTIONS --show-bpf-events Display bpf events i.e. events of type PERF_RECORD_KSYMBOL and PERF_RECORD_BPF_EVENT. +--show-all-events + Display all side-band events i.e. enable all --show-*-events options. + --demangle:: Demangle symbol names to human readable form. It's enabled by default, disable with --no-demangle.
tools/perf/builtin-script.c +13 -0
@@ -1607,6 +1607,7 @@ struct perf_script {bool show_lost_events;bool show_round_events;bool show_bpf_events; +bool show_all_events;bool allocated;bool per_event_dump;struct cpu_map *cpus;
@@ -2436,6 +2437,16 @@ static int __cmd_script(struct perf_script *script)perf_stat__init_shadow_stats (); +if (script->show_all_events) { + script->show_task_events = true; + script->show_mmap_events = true; + script->show_switch_events = true; + script->show_namespace_events = true; + script->show_lost_events = true; + script->show_round_events = true; + script->show_bpf_events = true; + } +/* override event processing functions */ if (script->show_task_events) { script->tool.comm = process_comm_event;
@@ -3481,6 +3492,8 @@ int cmd_script(int argc, const char **argv) "Show round events (if recorded)"),OPT_BOOLEAN ('\0' ,"show-bpf-events" , &script.show_bpf_events,"Show bpf related events (if recorded)" ), +OPT_BOOLEAN ('\0' ,"show-all-events" , &script.show_all_events, +"Show all side-band events (if recorded)" ),OPT_BOOLEAN ('\0' ,"per-event-dump" , &script.per_event_dump,"Dump trace output to files named by the monitored events" ), OPT_BOOLEAN('f', "force", &symbol_conf.force, "don't complain, do it"),
Signature · 1 line
2.20.1
Re: [PATCH 12/12] perf script: Add --show-all-events option
Em Wed, May 08, 2019 at 03:20:10PM +0200, Jiri Olsa escreveu:
Quoted 14 lines
Adding --show-all-events option to show all
side-bad events with single option, like:$ perf script --show-all-events swapper 0 [000] 0.000000: PERF_RECORD_MMAP -1/0: [0xffffffffa6000000(0xc00e41) @ 0xffffffffa6000000]: x [kernel.kallsyms]_text ... swapper 0 [000] 0.000000: PERF_RECORD_KSYMBOL addr ffffffffc01bc362 len 229 type 1 flags 0x0 name bpf_prog_7be49e3934a125ba swapper 0 [000] 0.000000: PERF_RECORD_BPF_EVENT type 1, flags 0, id 29 ... swapper 0 [000] 0.000000: PERF_RECORD_FORK(1:1):(0:0) systemd 0 [000] 0.000000: PERF_RECORD_COMM: systemd:1/1 ... swapper 0 [000] 63587.039518: 1 cycles: ffffffffa60698b4 [unknown] ([kernel.kallsyms]) swapper 0 [000] 63587.039522: 1 cycles: ffffffffa60698b4 [unknown] ([kernel.kallsyms])
Strange:
[root@quaco pt]#
[root@quaco pt]# perf evlist -v
intel_pt//ku: type: 8, size: 112, config: 0x300e601, { sample_period, sample_freq }: 1, sample_type: IP|TID|TIME|CPU|IDENTIFIER, read_format: ID, disabled: 1, inherit: 1, exclude_hv: 1, sample_id_all: 1
dummy:u: type: 1, size: 112, config: 0x9, { sample_period, sample_freq }: 1, sample_type: IP|TID|TIME|CPU|IDENTIFIER, read_format: ID, inherit: 1, exclude_kernel: 1, exclude_hv: 1, mmap: 1, comm: 1, task: 1, sample_id_all: 1, mmap2: 1, comm_exec: 1, context_switch: 1, ksymbol: 1, bpf_event: 1 [root@quaco pt]#
Then:
[root@quaco pt]# perf script --show-bpf-events | head
0 PERF_RECORD_KSYMBOL addr ffffffffc029a6c3 len 229 type 1 flags 0x0 name bpf_prog_7be49e3934a125ba 0 PERF_RECORD_BPF_EVENT type 1, flags 0, id 47
0 PERF_RECORD_KSYMBOL addr ffffffffc029c1ae len 229 type 1 flags 0x0 name bpf_prog_2a142ef67aaad174 0 PERF_RECORD_BPF_EVENT type 1, flags 0, id 48
0 PERF_RECORD_KSYMBOL addr ffffffffc02ddd1c len 229 type 1 flags 0x0 name bpf_prog_7be49e3934a125ba 0 PERF_RECORD_BPF_EVENT type 1, flags 0, id 49
0 PERF_RECORD_KSYMBOL addr ffffffffc02dfc11 len 229 type 1 flags 0x0 name bpf_prog_2a142ef67aaad174 0 PERF_RECORD_BPF_EVENT type 1, flags 0, id 50
0 PERF_RECORD_KSYMBOL addr ffffffffc045da0a len 229 type 1 flags 0x0 name bpf_prog_7be49e3934a125ba 0 PERF_RECORD_BPF_EVENT type 1, flags 0, id 51
[root@quaco pt]#
But:
[root@quaco pt]# perf script --show-all-events | head Intel Processor Trace requires ordered events 0x2a0 [0x60]: failed to process type: 1 [Invalid argument] [root@quaco pt]#
So I have all patches but this last one, will test and push Ingo's way so that we make progress, we can get this one later after we figure this out.
- Arnaldo
Re: [PATCH 12/12] perf script: Add --show-all-events option
Quoted 39 lines · Arnaldo Carvalho de Melo
Em Wed, May 08, 2019 at 03:20:10PM +0200, Jiri Olsa escreveu:
Quoted 14 lines
Adding --show-all-events option to show all
side-bad events with single option, like:$ perf script --show-all-events swapper 0 [000] 0.000000: PERF_RECORD_MMAP -1/0: [0xffffffffa6000000(0xc00e41) @ 0xffffffffa6000000]: x [kernel.kallsyms]_text ... swapper 0 [000] 0.000000: PERF_RECORD_KSYMBOL addr ffffffffc01bc362 len 229 type 1 flags 0x0 name bpf_prog_7be49e3934a125ba swapper 0 [000] 0.000000: PERF_RECORD_BPF_EVENT type 1, flags 0, id 29 ... swapper 0 [000] 0.000000: PERF_RECORD_FORK(1:1):(0:0) systemd 0 [000] 0.000000: PERF_RECORD_COMM: systemd:1/1 ... swapper 0 [000] 63587.039518: 1 cycles: ffffffffa60698b4 [unknown] ([kernel.kallsyms]) swapper 0 [000] 63587.039522: 1 cycles: ffffffffa60698b4 [unknown] ([kernel.kallsyms])Strange:
[root@quaco pt]#
[root@quaco pt]# perf evlist -v
intel_pt//ku: type: 8, size: 112, config:0x300e601, {sample_period,sample_freq}: 1,sample_type: IP|TID|TIME|CPU|IDENTIFIER,read_format: ID, disabled: 1, inherit: 1,exclude_hv: 1,sample_id_all: 1
dummy:u: type: 1, size: 112, config:0x9, {sample_period,sample_freq}: 1,sample_type: IP|TID|TIME|CPU|IDENTIFIER,read_format: ID, inherit: 1,exclude_kernel: 1,exclude_hv: 1, mmap: 1, comm: 1, task: 1,sample_id_all: 1, mmap2: 1,comm_exec: 1,context_switch: 1, ksymbol: 1,bpf_event: 1 [root@quaco pt]#Then:
[root@quaco pt]# perf script --show-bpf-events | head
0PERF_RECORD_KSYMBOLaddrffffffffc029a6c3len 229 type 1 flags0x0namebpf_prog_7be49e3934a125ba0PERF_RECORD_BPF_EVENTtype 1, flags 0, id 47
0PERF_RECORD_KSYMBOLaddrffffffffc029c1aelen 229 type 1 flags0x0namebpf_prog_2a142ef67aaad1740PERF_RECORD_BPF_EVENTtype 1, flags 0, id 48
0PERF_RECORD_KSYMBOLaddrffffffffc02ddd1clen 229 type 1 flags0x0namebpf_prog_7be49e3934a125ba0PERF_RECORD_BPF_EVENTtype 1, flags 0, id 49
0PERF_RECORD_KSYMBOLaddrffffffffc02dfc11len 229 type 1 flags0x0namebpf_prog_2a142ef67aaad1740PERF_RECORD_BPF_EVENTtype 1, flags 0, id 50
0PERF_RECORD_KSYMBOLaddrffffffffc045da0alen 229 type 1 flags0x0namebpf_prog_7be49e3934a125ba0PERF_RECORD_BPF_EVENTtype 1, flags 0, id 51
[root@quaco pt]#
Quoted 6 lines
But:
[root@quaco pt]# perf script --show-all-events | head Intel Processor Trace requires ordered events
0x2a0[0x60]: failed to process type: 1 [Invalid argument] [root@quaco pt]#
hum, so round events disable ordering, which is required by pt
if (script->show_round_events) {
script->tool.ordered_events = false;
..so the --show-round-events option always fails on intel_pt data:
[jolsa@krava perf]$ ./perf script --show-round-events Intel Processor Trace requires ordered events 0x2e8 [0x38]: failed to process type: 3 [Invalid argument]
Quoted 4 lines
So I have all patches but this last one, will test and push Ingo's way so that we make progress, we can get this one later after we figure this out.
thanks,
jirka
Quoted 94 lines · Jiri Olsa
hi,
this patchset adds dso support to read and display bpf code inintel_pttrace output. I had to change some of the kernel maps processing code, so hopefully I did not break too many things ;-)It's now possible to see bpf code flow via:
# perf-with-kcore record pt -e intel_pt//ku -- sleep 1 # perf-with-kcore script pt --insn-trace --xed ... sleep 36660 [016] 1057036.806464404: ffffffff811dfba5 trace_call_bpf+0x65 ([kernel.kallsyms]) nopl %eax, (%rax,%rax,1) sleep 36660 [016] 1057036.806464404: ffffffff811dfbaa trace_call_bpf+0x6a ([kernel.kallsyms]) movq 0x30(%rbx), %rax sleep 36660 [016] 1057036.806464404: ffffffff811dfbae trace_call_bpf+0x6e ([kernel.kallsyms]) leaq 0x38(%rbx), %rsi sleep 36660 [016] 1057036.806464404: ffffffff811dfbb2 trace_call_bpf+0x72 ([kernel.kallsyms]) mov %r13, %rdi sleep 36660 [016] 1057036.806464404: ffffffff811dfbb5 trace_call_bpf+0x75 ([kernel.kallsyms]) callq 0xffffffff81c00c30 sleep 36660 [016] 1057036.806464404: ffffffff81c00c30 __x86_indirect_thunk_rax+0x0 ([kernel.kallsyms]) callq 0xffffffff81c00c3c sleep 36660 [016] 1057036.806464404: ffffffff81c00c3c __x86_indirect_thunk_rax+0xc ([kernel.kallsyms]) movq %rax, (%rsp) sleep 36660 [016] 1057036.806464404: ffffffff81c00c40 __x86_indirect_thunk_rax+0x10 ([kernel.kallsyms]) retq sleep 36660 [016] 1057036.806464725: ffffffffa05e89ef bpf_prog_da4fe6b3d2c29b25_trace_return+0x0 (bpf_prog_da4fe6b3d2c29b25_trace_return) pushq %rbp sleep 36660 [016] 1057036.806464725: ffffffffa05e89f0 bpf_prog_da4fe6b3d2c29b25_trace_return+0x1 (bpf_prog_da4fe6b3d2c29b25_trace_return) mov %rsp, %rbp sleep 36660 [016] 1057036.806464725: ffffffffa05e89f3 bpf_prog_da4fe6b3d2c29b25_trace_return+0x4 (bpf_prog_da4fe6b3d2c29b25_trace_return) sub $0x158, %rsp sleep 36660 [016] 1057036.806464725: ffffffffa05e89fa bpf_prog_da4fe6b3d2c29b25_trace_return+0xb (bpf_prog_da4fe6b3d2c29b25_trace_return) sub $0x28, %rbp sleep 36660 [016] 1057036.806464725: ffffffffa05e89fe bpf_prog_da4fe6b3d2c29b25_trace_return+0xf (bpf_prog_da4fe6b3d2c29b25_trace_return) movq %rbx, (%rbp) sleep 36660 [016] 1057036.806464725: ffffffffa05e8a02 bpf_prog_da4fe6b3d2c29b25_trace_return+0x13 (bpf_prog_da4fe6b3d2c29b25_trace_return) movq %r13, 0x8(%rbp) sleep 36660 [016] 1057036.806464725: ffffffffa05e8a06 bpf_prog_da4fe6b3d2c29b25_trace_return+0x17 (bpf_prog_da4fe6b3d2c29b25_trace_return) movq %r14, 0x10(%rbp) sleep 36660 [016] 1057036.806464725: ffffffffa05e8a0a bpf_prog_da4fe6b3d2c29b25_trace_return+0x1b (bpf_prog_da4fe6b3d2c29b25_trace_return) movq %r15, 0x18(%rbp) sleep 36660 [016] 1057036.806464725: ffffffffa05e8a0e bpf_prog_da4fe6b3d2c29b25_trace_return+0x1f (bpf_prog_da4fe6b3d2c29b25_trace_return) xor %eax, %eax sleep 36660 [016] 1057036.806464725: ffffffffa05e8a10 bpf_prog_da4fe6b3d2c29b25_trace_return+0x21 (bpf_prog_da4fe6b3d2c29b25_trace_return) movq %rax, 0x20(%rbp) sleep 36660 [016] 1057036.806464725: ffffffffa05e8a14 bpf_prog_da4fe6b3d2c29b25_trace_return+0x25 (bpf_prog_da4fe6b3d2c29b25_trace_return) mov %rdi, %rbx sleep 36660 [016] 1057036.806464725: ffffffffa05e8a17 bpf_prog_da4fe6b3d2c29b25_trace_return+0x28 (bpf_prog_da4fe6b3d2c29b25_trace_return) callq 0xffffffff811fed50 sleep 36660 [016] 1057036.806464725: ffffffff811fed50 bpf_get_current_pid_tgid+0x0 ([kernel.kallsyms]) nopl %eax, (%rax,%rax,1) sleep 36660 [016] 1057036.806464725: ffffffff811fed55 bpf_get_current_pid_tgid+0x5 ([kernel.kallsyms]) movq %gs:0x15c00, %rdx sleep 36660 [016] 1057036.806464725: ffffffff811fed5e bpf_get_current_pid_tgid+0xe ([kernel.kallsyms]) test %rdx, %rdx sleep 36660 [016] 1057036.806464725: ffffffff811fed61 bpf_get_current_pid_tgid+0x11 ([kernel.kallsyms]) jz 0xffffffff811fed79 sleep 36660 [016] 1057036.806464725: ffffffff811fed63 bpf_get_current_pid_tgid+0x13 ([kernel.kallsyms]) movsxdl 0x494(%rdx), %rax sleep 36660 [016] 1057036.806464725: ffffffff811fed6a bpf_get_current_pid_tgid+0x1a ([kernel.kallsyms]) movsxdl 0x490(%rdx), %rdx sleep 36660 [016] 1057036.806464725: ffffffff811fed71 bpf_get_current_pid_tgid+0x21 ([kernel.kallsyms]) shl $0x20, %rax sleep 36660 [016] 1057036.806464725: ffffffff811fed75 bpf_get_current_pid_tgid+0x25 ([kernel.kallsyms]) or %rdx, %rax sleep 36660 [016] 1057036.806464725: ffffffff811fed78 bpf_get_current_pid_tgid+0x28 ([kernel.kallsyms]) retq sleep 36660 [016] 1057036.806464725: ffffffffa05e8a1c bpf_prog_da4fe6b3d2c29b25_trace_return+0x2d (bpf_prog_da4fe6b3d2c29b25_trace_return) movq %rax, -0x8(%rbp) sleep 36660 [016] 1057036.806464725: ffffffffa05e8a20 bpf_prog_da4fe6b3d2c29b25_trace_return+0x31 (bpf_prog_da4fe6b3d2c29b25_trace_return) xor %edi, %edi sleep 36660 [016] 1057036.806464725: ffffffffa05e8a22 bpf_prog_da4fe6b3d2c29b25_trace_return+0x33 (bpf_prog_da4fe6b3d2c29b25_trace_return) movq %rdi, -0x10(%rbp) sleep 36660 [016] 1057036.806464725: ffffffffa05e8a26 bpf_prog_da4fe6b3d2c29b25_trace_return+0x37 (bpf_prog_da4fe6b3d2c29b25_trace_return) movq %rdi, -0x18(%rbp)# perf-core/perf-with-kcore script pt --call-trace ... sleep 36660 [016] 1057036.806464404: ([kernel.kallsyms] ) kretprobe_perf_func sleep 36660 [016] 1057036.806464404: ([kernel.kallsyms] ) trace_call_bpf sleep 36660 [016] 1057036.806464404: ([kernel.kallsyms] ) __x86_indirect_thunk_rax sleep 36660 [016] 1057036.806464404: ([kernel.kallsyms] ) __x86_indirect_thunk_rax sleep 36660 [016] 1057036.806464725: (bpf_prog_da4fe6b3d2c29b25_trace_return ) bpf_get_current_pid_tgid sleep 36660 [016] 1057036.806464725: (bpf_prog_da4fe6b3d2c29b25_trace_return ) bpf_ktime_get_ns sleep 36660 [016] 1057036.806464725: ([kernel.kallsyms] ) __x86_indirect_thunk_rax sleep 36660 [016] 1057036.806464725: ([kernel.kallsyms] ) __x86_indirect_thunk_rax sleep 36660 [016] 1057036.806465045: (bpf_prog_da4fe6b3d2c29b25_trace_return ) __htab_map_lookup_elem sleep 36660 [016] 1057036.806465366: ([kernel.kallsyms] ) memcmp sleep 36660 [016] 1057036.806465687: (bpf_prog_da4fe6b3d2c29b25_trace_return ) bpf_probe_read sleep 36660 [016] 1057036.806465687: ([kernel.kallsyms] ) probe_kernel_read sleep 36660 [016] 1057036.806465687: ([kernel.kallsyms] ) __check_object_size sleep 36660 [016] 1057036.806465687: ([kernel.kallsyms] ) check_stack_object sleep 36660 [016] 1057036.806465687: ([kernel.kallsyms] ) copy_user_enhanced_fast_string sleep 36660 [016] 1057036.806465687: (bpf_prog_da4fe6b3d2c29b25_trace_return ) bpf_probe_read sleep 36660 [016] 1057036.806465687: ([kernel.kallsyms] ) probe_kernel_read sleep 36660 [016] 1057036.806465687: ([kernel.kallsyms] ) __check_object_size sleep 36660 [016] 1057036.806465687: ([kernel.kallsyms] ) check_stack_object sleep 36660 [016] 1057036.806465687: ([kernel.kallsyms] ) copy_user_enhanced_fast_string sleep 36660 [016] 1057036.806466008: (bpf_prog_da4fe6b3d2c29b25_trace_return ) bpf_get_current_uid_gid sleep 36660 [016] 1057036.806466008: ([kernel.kallsyms] ) from_kgid sleep 36660 [016] 1057036.806466008: ([kernel.kallsyms] ) from_kuid sleep 36660 [016] 1057036.806466008: (bpf_prog_da4fe6b3d2c29b25_trace_return ) bpf_perf_event_output sleep 36660 [016] 1057036.806466328: ([kernel.kallsyms] ) perf_event_output sleep 36660 [016] 1057036.806466328: ([kernel.kallsyms] ) perf_prepare_sample sleep 36660 [016] 1057036.806466328: ([kernel.kallsyms] ) perf_misc_flags sleep 36660 [016] 1057036.806466328: ([kernel.kallsyms] ) __x86_indirect_thunk_rax sleep 36660 [016] 1057036.806466328: ([kernel.kallsyms] ) __x86_indirect_thunk_raxv3 changes:
- fix the padding code in patch 7 (Song Liu)
- rebased on current Arnaldo's perf/core with merged perf/urgentv2 changes:
- fix missingpthread_mutex_unlock[Stanislav Fomichev]
- removed eBPF dso reusing [Adrian Hunter]
- merge eBPF and kcore maps [Adrian Hunter]
- few patches already applied
- added some perf script helper options
- patches are rebased on top of Arnaldo's perf/core with perf/urgent merged in
Quoted 7 lines
It's also available in here:
git://git.kernel.org/pub/scm/linux/kernel/git/jolsa/perf.git
perf/fixesthanks,
jirka
For the series:
Thanks!
Quoted 36 lines
Cc Jesper Dangaard Brouer <[email protected]>Cc Alexei Starovoitov <[email protected]>Cc Daniel Borkmann <[email protected]>---
Jiri Olsa (12):
perf tools: Separate generic code indso__data_file_sizeperf tools: Separate generic code indso_cache__readperf tools: Simplifydso_cache__readfunction
perf tools: Add bpf dso read and size hooks
perf tools: Read also the end of the kernel
perf tools: Keep zero in pgoff bpf map
perf script: Pad dso name for --call-trace
perf tools: Preserve eBPF maps when loading kcore perf tests: Addmap_groups__merge_intest
perf script: Add --show-bpf-events to show eBPF related events perf script: Remove superfluous bpf event titles perf script: Add --show-all-events optiontools/include/linux/kernel.h | 1 + tools/lib/vsprintf.c | 19 +++++++++++++++++++ tools/perf/Documentation/perf-script.txt | 6 ++++++ tools/perf/builtin-script.c | 56 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++ tools/perf/tests/Build | 1 + tools/perf/tests/builtin-test.c | 4 ++++ tools/perf/tests/map_groups.c | 120 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ tools/perf/tests/tests.h | 1 + tools/perf/util/dso.c | 125 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++------------------------------------ tools/perf/util/event.c | 4 ++-- tools/perf/util/machine.c | 31 ++++++++++++++++++++----------- tools/perf/util/map.c | 6 ++++++ tools/perf/util/map_groups.h | 2 ++ tools/perf/util/symbol.c | 97 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++---- tools/perf/util/symbol_conf.h | 1 + 15 files changed, 421 insertions(+), 53 deletions(-)create mode 100644
tools/perf/tests/map_groups.c
Quoted 7 lines
Quoted 1 line
- patches are rebased on top of Arnaldo's perf/core with perf/urgent
merged in
Quoted 5 lines
It's also available in here:
git://git.kernel.org/pub/scm/linux/kernel/git/jolsa/perf.git
perf/fixes
Quoted 7 lines
Quoted 3 lines
thanks,
jirkaFor the series:
Acked-by Song Liu <[email protected]>
Monday I'll test and apply, thanks!
- Arnaldo
Em Wed, May 08, 2019 at 03:19:58PM +0200, Jiri Olsa escreveu:
Quoted 5 lines
hi,
this patchset adds dso support to read and display bpf code inintel_pttrace output. I had to change some of the kernel maps processing code, so hopefully I did not break too many things ;-)
One of these patches need some uintptr_t (IIRC) somewhere:
CC /tmp/build/perf/util/color_config.outil/dso.c: In function 'bpf_read':util/dso.c:725:8: error: cast to pointer from integer of different size [-Werror=int-to-pointer-cast]
buf = (u8 *) node->info_linear->info.jited_prog_insns;
^ CC /tmp/build/perf/util/metricgroup.o
Several 32-bit cross builds failed:
51 30.64 ubuntu:16.04-x-arm : FAIL arm-linux-gnueabihf-gcc (Ubuntu/Linaro 5.4.0-6ubuntu1~16.04.9) 5.4.0 20160609 52 74.89 ubuntu:16.04-x-arm64 : Ok aarch64-linux-gnu-gcc (Ubuntu/Linaro 5.4.0-6ubuntu1~16.04.9) 5.4.0 20160609 53 32.23 ubuntu:16.04-x-powerpc : FAIL powerpc-linux-gnu-gcc (Ubuntu 5.4.0-6ubuntu1~16.04.9) 5.4.0 20160609 54 75.33 ubuntu:16.04-x-powerpc64 : Ok powerpc64-linux-gnu-gcc (Ubuntu/IBM 5.4.0-6ubuntu1~16.04.9) 5.4.0 20160609 55 75.96 ubuntu:16.04-x-powerpc64el : Ok powerpc64le-linux-gnu-gcc (Ubuntu/IBM 5.4.0-6ubuntu1~16.04.9) 5.4.0 20160609 56 71.70 ubuntu:16.04-x-s390 : Ok s390x-linux-gnu-gcc (Ubuntu 5.4.0-6ubuntu1~16.04.9) 5.4.0 20160609 57 280.83 ubuntu:17.10 : Ok gcc (Ubuntu 7.2.0-8ubuntu3.2) 7.2.0 58 274.85 ubuntu:18.04 : Ok gcc (Ubuntu 7.4.0-1ubuntu1~18.04) 7.4.0 59 33.88 ubuntu:18.04-x-arm : FAIL arm-linux-gnueabihf-gcc (Ubuntu/Linaro 7.4.0-1ubuntu1~18.04) 7.4.0 60 84.57 ubuntu:18.04-x-arm64 : Ok aarch64-linux-gnu-gcc (Ubuntu/Linaro 7.4.0-1ubuntu1~18.04) 7.4.0 61 27.01 ubuntu:18.04-x-m68k : FAIL m68k-linux-gnu-gcc (Ubuntu 7.4.0-1ubuntu1~18.04) 7.4.0 62 34.56 ubuntu:18.04-x-powerpc : FAIL powerpc-linux-gnu-gcc (Ubuntu 7.4.0-1ubuntu1~18.04) 7.4.0 63 87.19 ubuntu:18.04-x-powerpc64 : Ok powerpc64-linux-gnu-gcc (Ubuntu 7.4.0-1ubuntu1~18.04) 7.4.0 64 88.42 ubuntu:18.04-x-powerpc64el : Ok powerpc64le-linux-gnu-gcc (Ubuntu 7.4.0-1ubuntu1~18.04) 7.4.0 65 150.80 ubuntu:18.04-x-riscv64 : Ok riscv64-linux-gnu-gcc (Ubuntu 7.4.0-1ubuntu1~18.04) 7.4.0 66 75.12 ubuntu:18.04-x-s390 : Ok s390x-linux-gnu-gcc (Ubuntu 7.4.0-1ubuntu1~18.04) 7.4.0 67 31.68 ubuntu:18.04-x-sh4 : FAIL sh4-linux-gnu-gcc (Ubuntu 7.4.0-1ubuntu1~18.04) 7.4.0 68 73.71 ubuntu:18.04-x-sparc64 : Ok sparc64-linux-gnu-gcc (Ubuntu 7.4.0-1ubuntu1~18.04) 7.4.0 69 263.82 ubuntu:18.10 : Ok gcc (Ubuntu 8.2.0-7ubuntu1) 8.2.0 70 261.61 ubuntu:19.04 : Ok gcc (Ubuntu 8.3.0-6ubuntu1) 8.3.0 71 71.94 ubuntu:19.04-x-alpha : Ok alpha-linux-gnu-gcc (Ubuntu 8.3.0-6ubuntu1) 8.3.0 72 87.70 ubuntu:19.04-x-arm64 : Ok aarch64-linux-gnu-gcc (Ubuntu/Linaro 8.3.0-6ubuntu1) 8.3.0 73 28.21 ubuntu:19.04-x-hppa : FAIL hppa-linux-gnu-gcc (Ubuntu 8.3.0-6ubuntu1) 8.3.0
Quoted 127 lines
It's now possible to see bpf code flow via:
# perf-with-kcore record pt -e intel_pt//ku -- sleep 1 # perf-with-kcore script pt --insn-trace --xed ... sleep 36660 [016] 1057036.806464404: ffffffff811dfba5 trace_call_bpf+0x65 ([kernel.kallsyms]) nopl %eax, (%rax,%rax,1) sleep 36660 [016] 1057036.806464404: ffffffff811dfbaa trace_call_bpf+0x6a ([kernel.kallsyms]) movq 0x30(%rbx), %rax sleep 36660 [016] 1057036.806464404: ffffffff811dfbae trace_call_bpf+0x6e ([kernel.kallsyms]) leaq 0x38(%rbx), %rsi sleep 36660 [016] 1057036.806464404: ffffffff811dfbb2 trace_call_bpf+0x72 ([kernel.kallsyms]) mov %r13, %rdi sleep 36660 [016] 1057036.806464404: ffffffff811dfbb5 trace_call_bpf+0x75 ([kernel.kallsyms]) callq 0xffffffff81c00c30 sleep 36660 [016] 1057036.806464404: ffffffff81c00c30 __x86_indirect_thunk_rax+0x0 ([kernel.kallsyms]) callq 0xffffffff81c00c3c sleep 36660 [016] 1057036.806464404: ffffffff81c00c3c __x86_indirect_thunk_rax+0xc ([kernel.kallsyms]) movq %rax, (%rsp) sleep 36660 [016] 1057036.806464404: ffffffff81c00c40 __x86_indirect_thunk_rax+0x10 ([kernel.kallsyms]) retq sleep 36660 [016] 1057036.806464725: ffffffffa05e89ef bpf_prog_da4fe6b3d2c29b25_trace_return+0x0 (bpf_prog_da4fe6b3d2c29b25_trace_return) pushq %rbp sleep 36660 [016] 1057036.806464725: ffffffffa05e89f0 bpf_prog_da4fe6b3d2c29b25_trace_return+0x1 (bpf_prog_da4fe6b3d2c29b25_trace_return) mov %rsp, %rbp sleep 36660 [016] 1057036.806464725: ffffffffa05e89f3 bpf_prog_da4fe6b3d2c29b25_trace_return+0x4 (bpf_prog_da4fe6b3d2c29b25_trace_return) sub $0x158, %rsp sleep 36660 [016] 1057036.806464725: ffffffffa05e89fa bpf_prog_da4fe6b3d2c29b25_trace_return+0xb (bpf_prog_da4fe6b3d2c29b25_trace_return) sub $0x28, %rbp sleep 36660 [016] 1057036.806464725: ffffffffa05e89fe bpf_prog_da4fe6b3d2c29b25_trace_return+0xf (bpf_prog_da4fe6b3d2c29b25_trace_return) movq %rbx, (%rbp) sleep 36660 [016] 1057036.806464725: ffffffffa05e8a02 bpf_prog_da4fe6b3d2c29b25_trace_return+0x13 (bpf_prog_da4fe6b3d2c29b25_trace_return) movq %r13, 0x8(%rbp) sleep 36660 [016] 1057036.806464725: ffffffffa05e8a06 bpf_prog_da4fe6b3d2c29b25_trace_return+0x17 (bpf_prog_da4fe6b3d2c29b25_trace_return) movq %r14, 0x10(%rbp) sleep 36660 [016] 1057036.806464725: ffffffffa05e8a0a bpf_prog_da4fe6b3d2c29b25_trace_return+0x1b (bpf_prog_da4fe6b3d2c29b25_trace_return) movq %r15, 0x18(%rbp) sleep 36660 [016] 1057036.806464725: ffffffffa05e8a0e bpf_prog_da4fe6b3d2c29b25_trace_return+0x1f (bpf_prog_da4fe6b3d2c29b25_trace_return) xor %eax, %eax sleep 36660 [016] 1057036.806464725: ffffffffa05e8a10 bpf_prog_da4fe6b3d2c29b25_trace_return+0x21 (bpf_prog_da4fe6b3d2c29b25_trace_return) movq %rax, 0x20(%rbp) sleep 36660 [016] 1057036.806464725: ffffffffa05e8a14 bpf_prog_da4fe6b3d2c29b25_trace_return+0x25 (bpf_prog_da4fe6b3d2c29b25_trace_return) mov %rdi, %rbx sleep 36660 [016] 1057036.806464725: ffffffffa05e8a17 bpf_prog_da4fe6b3d2c29b25_trace_return+0x28 (bpf_prog_da4fe6b3d2c29b25_trace_return) callq 0xffffffff811fed50 sleep 36660 [016] 1057036.806464725: ffffffff811fed50 bpf_get_current_pid_tgid+0x0 ([kernel.kallsyms]) nopl %eax, (%rax,%rax,1) sleep 36660 [016] 1057036.806464725: ffffffff811fed55 bpf_get_current_pid_tgid+0x5 ([kernel.kallsyms]) movq %gs:0x15c00, %rdx sleep 36660 [016] 1057036.806464725: ffffffff811fed5e bpf_get_current_pid_tgid+0xe ([kernel.kallsyms]) test %rdx, %rdx sleep 36660 [016] 1057036.806464725: ffffffff811fed61 bpf_get_current_pid_tgid+0x11 ([kernel.kallsyms]) jz 0xffffffff811fed79 sleep 36660 [016] 1057036.806464725: ffffffff811fed63 bpf_get_current_pid_tgid+0x13 ([kernel.kallsyms]) movsxdl 0x494(%rdx), %rax sleep 36660 [016] 1057036.806464725: ffffffff811fed6a bpf_get_current_pid_tgid+0x1a ([kernel.kallsyms]) movsxdl 0x490(%rdx), %rdx sleep 36660 [016] 1057036.806464725: ffffffff811fed71 bpf_get_current_pid_tgid+0x21 ([kernel.kallsyms]) shl $0x20, %rax sleep 36660 [016] 1057036.806464725: ffffffff811fed75 bpf_get_current_pid_tgid+0x25 ([kernel.kallsyms]) or %rdx, %rax sleep 36660 [016] 1057036.806464725: ffffffff811fed78 bpf_get_current_pid_tgid+0x28 ([kernel.kallsyms]) retq sleep 36660 [016] 1057036.806464725: ffffffffa05e8a1c bpf_prog_da4fe6b3d2c29b25_trace_return+0x2d (bpf_prog_da4fe6b3d2c29b25_trace_return) movq %rax, -0x8(%rbp) sleep 36660 [016] 1057036.806464725: ffffffffa05e8a20 bpf_prog_da4fe6b3d2c29b25_trace_return+0x31 (bpf_prog_da4fe6b3d2c29b25_trace_return) xor %edi, %edi sleep 36660 [016] 1057036.806464725: ffffffffa05e8a22 bpf_prog_da4fe6b3d2c29b25_trace_return+0x33 (bpf_prog_da4fe6b3d2c29b25_trace_return) movq %rdi, -0x10(%rbp) sleep 36660 [016] 1057036.806464725: ffffffffa05e8a26 bpf_prog_da4fe6b3d2c29b25_trace_return+0x37 (bpf_prog_da4fe6b3d2c29b25_trace_return) movq %rdi, -0x18(%rbp)# perf-core/perf-with-kcore script pt --call-trace ... sleep 36660 [016] 1057036.806464404: ([kernel.kallsyms] ) kretprobe_perf_func sleep 36660 [016] 1057036.806464404: ([kernel.kallsyms] ) trace_call_bpf sleep 36660 [016] 1057036.806464404: ([kernel.kallsyms] ) __x86_indirect_thunk_rax sleep 36660 [016] 1057036.806464404: ([kernel.kallsyms] ) __x86_indirect_thunk_rax sleep 36660 [016] 1057036.806464725: (bpf_prog_da4fe6b3d2c29b25_trace_return ) bpf_get_current_pid_tgid sleep 36660 [016] 1057036.806464725: (bpf_prog_da4fe6b3d2c29b25_trace_return ) bpf_ktime_get_ns sleep 36660 [016] 1057036.806464725: ([kernel.kallsyms] ) __x86_indirect_thunk_rax sleep 36660 [016] 1057036.806464725: ([kernel.kallsyms] ) __x86_indirect_thunk_rax sleep 36660 [016] 1057036.806465045: (bpf_prog_da4fe6b3d2c29b25_trace_return ) __htab_map_lookup_elem sleep 36660 [016] 1057036.806465366: ([kernel.kallsyms] ) memcmp sleep 36660 [016] 1057036.806465687: (bpf_prog_da4fe6b3d2c29b25_trace_return ) bpf_probe_read sleep 36660 [016] 1057036.806465687: ([kernel.kallsyms] ) probe_kernel_read sleep 36660 [016] 1057036.806465687: ([kernel.kallsyms] ) __check_object_size sleep 36660 [016] 1057036.806465687: ([kernel.kallsyms] ) check_stack_object sleep 36660 [016] 1057036.806465687: ([kernel.kallsyms] ) copy_user_enhanced_fast_string sleep 36660 [016] 1057036.806465687: (bpf_prog_da4fe6b3d2c29b25_trace_return ) bpf_probe_read sleep 36660 [016] 1057036.806465687: ([kernel.kallsyms] ) probe_kernel_read sleep 36660 [016] 1057036.806465687: ([kernel.kallsyms] ) __check_object_size sleep 36660 [016] 1057036.806465687: ([kernel.kallsyms] ) check_stack_object sleep 36660 [016] 1057036.806465687: ([kernel.kallsyms] ) copy_user_enhanced_fast_string sleep 36660 [016] 1057036.806466008: (bpf_prog_da4fe6b3d2c29b25_trace_return ) bpf_get_current_uid_gid sleep 36660 [016] 1057036.806466008: ([kernel.kallsyms] ) from_kgid sleep 36660 [016] 1057036.806466008: ([kernel.kallsyms] ) from_kuid sleep 36660 [016] 1057036.806466008: (bpf_prog_da4fe6b3d2c29b25_trace_return ) bpf_perf_event_output sleep 36660 [016] 1057036.806466328: ([kernel.kallsyms] ) perf_event_output sleep 36660 [016] 1057036.806466328: ([kernel.kallsyms] ) perf_prepare_sample sleep 36660 [016] 1057036.806466328: ([kernel.kallsyms] ) perf_misc_flags sleep 36660 [016] 1057036.806466328: ([kernel.kallsyms] ) __x86_indirect_thunk_rax sleep 36660 [016] 1057036.806466328: ([kernel.kallsyms] ) __x86_indirect_thunk_raxv3 changes:
- fix the padding code in patch 7 (Song Liu)
- rebased on current Arnaldo's perf/core with merged perf/urgentv2 changes:
- fix missingpthread_mutex_unlock[Stanislav Fomichev]
- removed eBPF dso reusing [Adrian Hunter]
- merge eBPF and kcore maps [Adrian Hunter]
- few patches already applied
- added some perf script helper options
- patches are rebased on top of Arnaldo's perf/core with perf/urgent merged inIt's also available in here:
git://git.kernel.org/pub/scm/linux/kernel/git/jolsa/perf.git
perf/fixesthanks,
jirkaCc Jesper Dangaard Brouer <[email protected]>Cc Alexei Starovoitov <[email protected]>Cc Daniel Borkmann <[email protected]>---
Jiri Olsa (12):
perf tools: Separate generic code indso__data_file_sizeperf tools: Separate generic code indso_cache__readperf tools: Simplifydso_cache__readfunction
perf tools: Add bpf dso read and size hooks
perf tools: Read also the end of the kernel
perf tools: Keep zero in pgoff bpf map
perf script: Pad dso name for --call-trace
perf tools: Preserve eBPF maps when loading kcore perf tests: Addmap_groups__merge_intest
perf script: Add --show-bpf-events to show eBPF related events perf script: Remove superfluous bpf event titles perf script: Add --show-all-events optiontools/include/linux/kernel.h | 1 + tools/lib/vsprintf.c | 19 +++++++++++++++++++ tools/perf/Documentation/perf-script.txt | 6 ++++++ tools/perf/builtin-script.c | 56 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++ tools/perf/tests/Build | 1 + tools/perf/tests/builtin-test.c | 4 ++++ tools/perf/tests/map_groups.c | 120 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ tools/perf/tests/tests.h | 1 + tools/perf/util/dso.c | 125 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++------------------------------------ tools/perf/util/event.c | 4 ++-- tools/perf/util/machine.c | 31 ++++++++++++++++++++----------- tools/perf/util/map.c | 6 ++++++ tools/perf/util/map_groups.h | 2 ++ tools/perf/util/symbol.c | 97 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++---- tools/perf/util/symbol_conf.h | 1 + 15 files changed, 421 insertions(+), 53 deletions(-) create mode 100644 tools/perf/tests/map_groups.c
Signature · 1 line
- Arnaldo
Quoted 7 lines · Arnaldo Carvalho de Melo
Em Wed, May 08, 2019 at 03:19:58PM +0200, Jiri Olsa escreveu:
Quoted 5 lines
hi,
this patchset adds dso support to read and display bpf code inintel_pttrace output. I had to change some of the kernel maps processing code, so hopefully I did not break too many things ;-)
Quoted 7 lines
One of these patches need some
uintptr_t(IIRC) somewhere:CC
/tmp/build/perf/util/color_config.outil/dso.c: In function 'bpf_read':util/dso.c:725:8: error: cast to pointer from integer of different size [-Werror=int-to-pointer-cast]buf = (u8 *) node->info_linear->info.jited_prog_insns; ^
would something like below help? we already do that in the annotation code
thanks,
jirka
---
tools/perf/util/dso.c +1 -1
@@ -722,7 +722,7 @@ static ssize_t bpf_read(struct dso *dso, u64 offset, char *data) } len = node->info_linear->info.jited_prog_len; - buf = (u8 *) node->info_linear->info.jited_prog_insns; + buf = (u8 *)(uintptr_t ) node->info_linear->info.jited_prog_insns;if (offset >= len)return -1 ;
Hi Jiri,
Quoted 10 lines · Jiri Olsa
hi,
this patchset adds dso support to read and display bpf code inintel_pttrace output. I had to change some of the kernel maps processing code, so hopefully I did not break too many things ;-)It's now possible to see bpf code flow via:
# perf-with-kcore record pt -e intel_pt//ku -- sleep 1 # perf-with-kcore script pt --insn-trace --xed
This is very interesting work for me!
I want to verify this feature with Arm CoreSight trace, I have one question so that I have more direction for the tesing:
What's the bpf program you are suing for the testing? e.g. some testing program under the kernel's folder $kernel/samples/bpf? Or you uses perf command to launch bpf program?
[...]
Thanks
Leo Yan
Quoted 14 lines · Leo Yan
Hi Jiri,
Quoted 10 lines · Jiri Olsa
hi,
this patchset adds dso support to read and display bpf code inintel_pttrace output. I had to change some of the kernel maps processing code, so hopefully I did not break too many things ;-)It's now possible to see bpf code flow via:
# perf-with-kcore record pt -e intel_pt//ku -- sleep 1 # perf-with-kcore script pt --insn-trace --xed
Quoted 8 lines
This is very interesting work for me!
I want to verify this feature with Arm CoreSight trace, I have one question so that I have more direction for the tesing:
What's the bpf program you are suing for the testing? e.g. some testing program under the kernel's folder $kernel/samples/bpf? Or you uses perf command to launch bpf program?
for this I was using tools/testing/selftests/bpf/test_verifier
I isolated some tests and ran the perf on top of them, like:
# perf-with-kcore record pt -e intel_pt//ku -- ./test_verifier ...
I had to add some small sleep before the test_verifier exit, so the perf bpf thread could catch up and download the program details before test_verifier exited.
jirka
Quoted 5 lines
[...]
Thanks
Leo Yan
Hi Jiri,
Quoted 24 lines · Jiri Olsa
Quoted 14 lines · Leo Yan
Hi Jiri,
Quoted 10 lines · Jiri Olsa
hi,
this patchset adds dso support to read and display bpf code inintel_pttrace output. I had to change some of the kernel maps processing code, so hopefully I did not break too many things ;-)It's now possible to see bpf code flow via:
# perf-with-kcore record pt -e intel_pt//ku -- sleep 1 # perf-with-kcore script pt --insn-trace --xedQuoted 8 lines
This is very interesting work for me!
I want to verify this feature with Arm CoreSight trace, I have one question so that I have more direction for the tesing:
What's the bpf program you are suing for the testing? e.g. some testing program under the kernel's folder $kernel/samples/bpf? Or you uses perf command to launch bpf program?
Quoted 5 lines
for this I was using
tools/testing/selftests/bpf/test_verifierI isolated some tests and ran the perf on top of them, like:
# perf-with-kcore record pt -e intel_pt//ku -- ./test_verifier ...
Thanks a lot for sharing the info and quick responsing.
I tried to use the program $kernel/samples/bpf/sampleip to verify this patch set, but seems eBPF dso is not contained properly; below is my detailed steps:
# In the first tty
# cd $kernel/samples/bpf/
# ./sampleip -F 200 20 => sample ip with 200Hz for 20s
# In the second tty
# perf-with-kcore record arm_test -e cs_etm/@20070000.etr/uk -- sleep 1
If I output DSO info with report command it give below info, which doesn't contain any info for eBPF DSO?
# perf-with-kcore report arm_test -F,dso
# Samples: 6M of event 'branches:ku'
# Event count (approx.): 6340896
#
# Shared Object
# ..................
#
[kernel.kallsyms]
ld-2.28.so
libc-2.28.so
libpthread-2.28.so
perf
sleep
[unknown] Quoted 3 lines
I had to add some small sleep before the
test_verifierexit, so the perf bpf thread could catch up and download the program details beforetest_verifierexited.
This seems to me for a 'real' eBPF program, do we also need extra sleep so that perf bpf can save dso properly?
BTW, I have another question: to display eBPF code, except this feature can be used by hardware tracing (e.g. intel_pt), it also can be used by other PMU events and timer events, right?
Thanks,
Leo Yan
Quoted 65 lines · Leo Yan
Hi Jiri,
Quoted 24 lines · Jiri Olsa
Quoted 14 lines · Leo Yan
Hi Jiri,
Quoted 10 lines · Jiri Olsa
hi,
this patchset adds dso support to read and display bpf code inintel_pttrace output. I had to change some of the kernel maps processing code, so hopefully I did not break too many things ;-)It's now possible to see bpf code flow via:
# perf-with-kcore record pt -e intel_pt//ku -- sleep 1 # perf-with-kcore script pt --insn-trace --xedQuoted 8 lines
This is very interesting work for me!
I want to verify this feature with Arm CoreSight trace, I have one question so that I have more direction for the tesing:
What's the bpf program you are suing for the testing? e.g. some testing program under the kernel's folder $kernel/samples/bpf? Or you uses perf command to launch bpf program?
Quoted 5 lines
for this I was using
tools/testing/selftests/bpf/test_verifierI isolated some tests and ran the perf on top of them, like:
# perf-with-kcore record pt -e intel_pt//ku -- ./test_verifier ...Thanks a lot for sharing the info and quick responsing.
I tried to use the program $kernel/samples/bpf/sampleip to verify this patch set, but seems eBPF dso is not contained properly; below is my detailed steps:
# In the first tty
# cd $kernel/samples/bpf/
# ./sampleip -F 200 20 => sample ip with 200Hz for 20s# In the second tty
# perf-with-kcore recordarm_test-e cs_etm/@20070000.etr/uk -- sleep 1If I output DSO info with report command it give below info, which doesn't contain any info for eBPF DSO?
# perf-with-kcore report arm_test -F,dso# Samples: 6M of event 'branches:ku' # Event count (approx.): 6340896 # # Shared Object # .................. # [kernel.kallsyms] ld-2.28.so libc-2.28.so libpthread-2.28.so perf sleep [unknown]
Quoted 6 lines
Quoted 3 lines
I had to add some small sleep before the
test_verifierexit, so the perf bpf thread could catch up and download the program details beforetest_verifierexited.This seems to me for a 'real' eBPF program, do we also need extra sleep so that perf bpf can save dso properly?
no it's just test_verifier exits right away with ebpf code, and perf does not have a chance to get the ebpf prog info
your example above should be fine.. I'll try
Quoted 4 lines
BTW, I have another question: to display eBPF code, except this feature can be used by hardware tracing (e.g.
intel_pt), it also can be used by other PMU events and timer events, right?
yes, the standard sample/annotate support was already in perf
jirka
Em Thu, May 30, 2019 at 08:57:09PM +0800, Leo Yan escreveu:
Quoted 51 lines
Hi Jiri,
Quoted 24 lines · Jiri Olsa
Quoted 14 lines · Leo Yan
Hi Jiri,
Quoted 10 lines · Jiri Olsa
hi,
this patchset adds dso support to read and display bpf code inintel_pttrace output. I had to change some of the kernel maps processing code, so hopefully I did not break too many things ;-)It's now possible to see bpf code flow via:
# perf-with-kcore record pt -e intel_pt//ku -- sleep 1 # perf-with-kcore script pt --insn-trace --xedQuoted 8 lines
This is very interesting work for me!
I want to verify this feature with Arm CoreSight trace, I have one question so that I have more direction for the tesing:
What's the bpf program you are suing for the testing? e.g. some testing program under the kernel's folder $kernel/samples/bpf? Or you uses perf command to launch bpf program?
Quoted 5 lines
for this I was using
tools/testing/selftests/bpf/test_verifierI isolated some tests and ran the perf on top of them, like:
# perf-with-kcore record pt -e intel_pt//ku -- ./test_verifier ...Thanks a lot for sharing the info and quick responsing.
I tried to use the program $kernel/samples/bpf/sampleip to verify this patch set, but seems eBPF dso is not contained properly; below is my detailed steps:
# In the first tty
# cd $kernel/samples/bpf/
# ./sampleip -F 200 20 => sample ip with 200Hz for 20s# In the second tty
# perf-with-kcore recordarm_test-e cs_etm/@20070000.etr/uk -- sleep 1If I output DSO info with report command it give below info, which doesn't contain any info for eBPF DSO?
# perf-with-kcore report arm_test -F,dso
Quoted 13 lines
# Samples: 6M of event 'branches:ku'
# Event count (approx.): 6340896
#
# Shared Object
# ..................
#
[kernel.kallsyms]
ld-2.28.so
libc-2.28.so
libpthread-2.28.so
perf
sleep
[unknown] One other way of testing this:
I used perf trace's use of BPF, using:
[root@quaco ~]# cat ~/.perfconfig
[llvm]
dump-obj = true
clang-opt = -g
[trace]
add_events = /home/acme/git/perf/tools/perf/examples/bpf/augmented_raw_syscalls.c show_zeros = yes
show_duration = no
no_inherit = yes
show_timestamp = no
show_arg_names = no
args_alignment = 40
show_prefix = yes
For arm64 this needs fixing, tools/perf/examples/bpf/augmented_raw_syscalls.c (its in the kernel sources) is still hard coded for x86_64 syscall numbers :-\
Use some other BPF workload, one that has its programs being hit so that we get samples in it, in my case running:
# perf trace
For system wide strace like tracing, which hooks in the raw_syscalls:sys_enter and raw_syscalls:sys_exit tracepoints, I got:
[root@quaco ~]# perf record -a sleep 2s
[ perf record: Woken up 1 times to write data ]
[ perf record: Captured and wrote 3.136 MB perf.data (32020 samples) ] [root@quaco ~]# perf report --stdio -s dso | head -40
# To display the perf.data header info, please use --header/--header-only options. #
#
# Total Lost Samples: 0
#
# Samples: 32K of event 'cycles'
# Event count (approx.): 6201422424
#
# Overhead Shared Object
# ........ ...................................
#
80.92% [kernel.vmlinux]
5.14% libxul.so
3.60% libc-2.28.so
1.88% sshd
1.18% trace
1.02% [nf_conntrack]
0.73% firefox
0.57% libcrypto.so.1.1.1b
0.50% libpthread-2.28.so
0.45% [r8152]
0.44% bpf_prog_2cf7fd321e9b084c_sys_enter
0.43% [JIT] tid 10475
0.39% bpf_prog_c1bd85c092d6e4aa_sys_exit
0.33% [unknown]
0.28% [JIT] tid 10033
0.21% [JIT] tid 7243
0.21% libglib-2.0.so.0.5800.3
0.14% [nf_nat]
0.13% [JIT] tid 9488
0.13% [vdso]
0.12% ld-2.28.so
0.09% [iptable_raw]
0.08% [kvm]
0.08% libpulsecore-12.2.so
0.07% [iptable_mangle]
0.06% libjansson.so.4.11.0
0.06% libpulsecommon-12.2.so
0.05% [nf_defrag_ipv4]
0.04% libasound.so.2.0.0
[root@quaco ~]#So you see those bpf_prog_2cf7fd321e9b084c_sys_enter and bpf_prog_c1bd85c092d6e4aa_sys_exit DSOs, those are the BPF proggies that 'perf trace' used clang to build and then hooked into the raw_syscalls tracepoints.
If I furthermore ask for annotating the only symbol in that DSO, I get source code intermixed with the BPF jitted code, make sure you use a recent enough clang version, here I'm using, looking at the dumped .o file (asked via ~/.perfconfig's llvm.dump-obj=y that has BTF info generated by clang because we have also llvm.clang-opt=-g there):
[root@quaco ~]# file /home/acme/git/perf/tools/perf/examples/bpf/augmented_raw_syscalls.o /home/acme/git/perf/tools/perf/examples/bpf/augmented_raw_syscalls.o: ELF 64-bit LSB relocatable, eBPF, version 1 (SYSV), with debug_info, not stripped [root@quaco ~]# eu-readelf -winfo /home/acme/git/perf/tools/perf/examples/bpf/augmented_raw_syscalls.o | grep -w producer
producer (strp) "clang version 9.0.0 (https://git.llvm.org/git/clang.git/ 7906282d3afec5dfdc2b27943fd6c0309086c507) (https://git.llvm.org/git/llvm.git/ a1b5de1ff8ae8bc79dc8e86e1f82565229bd0500)" [root@quaco ~]# readelf -SW /home/acme/git/perf/tools/perf/examples/bpf/augmented_raw_syscalls.o | grep -i BTF [23] .BTF PROGBITS 0000000000000000 00229c 000c03 00 0 0 1 [24] .BTF.ext PROGBITS 0000000000000000 002e9f 000300 00 0 0 1 [25] .rel.BTF.ext REL 0000000000000000 004700 0002d0 10 31 24 8
[root@quaco ~]#
# perf annotate --stdio2 bpf_prog_2cf7fd321e9b084c_sys_enter Samples: 107 of event 'cycles', 4000 Hz, Event count (approx.): 27440959, [percent: local period] bpf_prog_2cf7fd321e9b084c_sys_enter() bpf_prog_2cf7fd321e9b084c_sys_enter Percent int sys_enter(struct syscall_enter_args *args) 65.78 push %rbp
0.48 mov %rsp,%rbp
sub $0x30,%rsp
1.41 sub $0x28,%rbp
10.66 mov %rbx,0x0(%rbp)
2.63 mov %r13,0x8(%rbp)
mov %r14,0x10(%rbp)
0.67 mov %r15,0x18(%rbp)
0.96 xor %eax,%eax
mov %rax,0x20(%rbp)
mov %rdi,%rbx
xor %edi,%edi
int key = 0;
0.70 mov %edi,-0x8(%rbp)
mov %rbp,%rsi
int sys_enter(struct syscall_enter_args *args)
0.68 add $0xfffffffffffffff8,%rsi
augmented_args = bpf_map_lookup_elem(&augmented_filename_map, &key);0.70 movabs $0xffff9c4bdf9d3800,%rdi
0.70 → callq *fffffffff98e80d5
mov %rax,%r13
mov $0x1,%eax
if (augmented_args == NULL)
4.20 cmp $0x0,%r13
↓ je 2b1
return bpf_get_current_pid_tgid();
→ callq *fffffffff98e4ac5
0.70 mov %eax,-0x4(%rbp)
mov %rbp,%rsi
add $0xfffffffffffffffc,%rsi
return bpf_map_lookup_elem(pids, &pid) != NULL;
0.70 movabs $0xffff9c4f01d6a000,%rdi0.67 → callq *fffffffff98e6085
cmp $0x0,%rax
↓ je 7d
add $0x38,%rax1.80 7d: mov %rax,%rdi
xor %eax,%eax
if (pid_filter__has(&pids_filtered, getpid()))
cmp $0x0,%rdi
↓ jne 2b1
probe_read(&augmented_args->args, sizeof(augmented_args->args), args);
0.29 mov %r13,%rdi
mov $0x40,%esi
mov %rbx,%rdx
→ callq *fffffffff98c4025
syscall = bpf_map_lookup_elem(&syscalls, &augmented_args->args.syscall_nr);
mov %r13,%r14
add $0x8,%r14
syscall = bpf_map_lookup_elem(&syscalls, &augmented_args->args.syscall_nr);
movabs $0xffff9c4efe8aa000,%rdi
mov %r14,%rsi
add $0xd0,%rdi
mov 0x0(%rsi),%eax
cmp $0x200,%rax
↓ jae cc
shl $0x3,%rax
add %rdi,%rax
↓ jmp ce
cc: xor %eax,%eax
ce: mov %rax,%rdi
xor %eax,%eax
if (syscall == NULL || !syscall->enabled)
cmp $0x0,%rdi
↓ je 2b1
if (syscall == NULL || !syscall->enabled)0.91 movzbq 0x0(%rdi),%rdi
xor %eax,%eax
if (syscall == NULL || !syscall->enabled)
cmp $0x0,%rdi
↓ je 2b1
mov $0x40,%r8d
switch (augmented_args->args.syscall_nr) {
mov 0x0(%r14),%rdi
switch (augmented_args->args.syscall_nr) {
cmp $0xef,%rdi
↓ jg 188
mov %rdi,%rdx
add $0xffffffffffffff65,%rdx
cmp $0x2c,%rdx
↓ ja 11a
↓ jmpq 20a
11a: mov %rdi,%rsi
add $0xffffffffffffffb4,%rsi
cmp $0x3d,%rsi
↓ ja 14b
mov $0x1,%edx
push %rcx
mov %rsi,%rcx
shl %cl,%rdx
pop %rcx
movabs $0x2200000000057fd1,%rsi
and %rsi,%rdx
cmp $0x0,%rdx
↓ jne 24b
14b: cmp $0x3b,%rdi
↓ ja 297
mov $0x1,%esi
push %rcx
mov %rdi,%rcx
shl %cl,%rsi
pop %rcx
movabs $0x800000000200054,%rdx
and %rdx,%rsi
cmp $0x0,%rsi
↓ jne 24b
cmp $0x12,%rdi
↓ je 245
↓ jmpq 297
188: mov %rdi,%rdx
add $0xffffffffffffff10,%rdx
cmp $0x3f,%rdx
↓ ja 1cc
mov $0x1,%esi
push %rcx
mov %rdx,%rcx
shl %cl,%rsi
pop %rcx
movabs $0x800001003bfe4004,%rdx
mov %rsi,%rcx
and %rdx,%rcx
cmp $0x0,%rcx
↓ jne 245
and $0x4000303,%rsi
cmp $0x0,%rsi
↓ jne 24b
1cc: mov %rdi,%rsi
add $0xfffffffffffffec7,%rsi
cmp $0x13,%rsi
↓ ja 1fc
mov $0x1,%edx
push %rcx
mov %rsi,%rcx
shl %cl,%rdx
pop %rcx
and $0x80209,%rdx
cmp $0x0,%rdx
↓ jne 245
cmp $0x6,%rsi
↓ je 24b
1fc: cmp $0x1b1,%rdi
↓ je 245
↓ jmpq 297
20a: mov $0x1,%esi
push %rcx
mov %rdx,%rcx
shl %cl,%rsi
pop %rcx
movabs $0xdb600203141,%rdx
mov %rsi,%rcx
and %rdx,%rcx
cmp $0x0,%rcx
↓ jne 24b
movabs $0x104801000000,%rdx
and %rdx,%rsi
cmp $0x0,%rsi
↓ jne 245
↑ jmpq 11a
case SYS_OPENAT: filename_arg = (const void *)args->args[1];
245: mov 0x18(%rbx),%rdx
↓ jmp 24f
case SYS_OPEN: filename_arg = (const void *)args->args[0];
24b: mov 0x10(%rbx),%rdx
if (filename_arg != NULL) {
24f: cmp $0x0,%rdx
↓ je 297
xor %edi,%edi
augmented_args->filename.reserved = 0;
mov %edi,0x44(%r13)
augmented_args->filename.size = probe_read_str(&augmented_args->filename.value,
mov %r13,%rdi
add $0x48,%rdi
augmented_args->filename.size = probe_read_str(&augmented_args->filename.value,
mov $0x1000,%esi
→ callq *fffffffff98c4135
augmented_args->filename.size = probe_read_str(&augmented_args->filename.value,
mov %eax,0x40(%r13)
mov $0x1048,%r8d
augmented_args->filename.size = probe_read_str(&augmented_args->filename.value,
mov %rax,%rdi
shl $0x20,%rdi
shr $0x20,%rdi
if (augmented_args->filename.size < sizeof(augmented_args->filename.value)) {
cmp $0xfff,%rdi
↓ ja 297
len -= sizeof(augmented_args->filename.value) - augmented_args->filename.size;
add $0x48,%rax
len &= sizeof(augmented_args->filename.value) - 1;
and $0xfff,%rax
mov %rax,%r8
return perf_event_output(args, &__augmented_syscalls__, BPF_F_CURRENT_CPU, augmented_args, len);
297: mov %rbx,%rdi
movabs $0xffff9c4bdf9d3a00,%rsi
mov $0xffffffff,%edx
mov %r13,%rcx
→ callq *fffffffff98c4775
}
3.52 2b1: mov 0x0(%rbp),%rbx
mov 0x8(%rbp),%r13
mov 0x10(%rbp),%r14
mov 0x18(%rbp),%r15
add $0x28,%rbp 1.84 leaveq
← retq
Look at the perf.data file for the required records, included in Linux v5.1:
[root@quaco ~]# perf report -D | egrep 'PERF_RECORD_(BPF|KSYMBOL)'
0 0 0x54f0 [0x50]: PERF_RECORD_KSYMBOL addr ffffffffc0240484 len 229 type 1 flags 0x0 name bpf_prog_7be49e3934a125ba
0 0 0x5540 [0x30]: PERF_RECORD_BPF_EVENT type 1, flags 0, id 13
0 0 0x5570 [0x50]: PERF_RECORD_KSYMBOL addr ffffffffc0283679 len 229 type 1 flags 0x0 name bpf_prog_2a142ef67aaad174
0 0 0x55c0 [0x30]: PERF_RECORD_BPF_EVENT type 1, flags 0, id 14
0 0 0x55f0 [0x50]: PERF_RECORD_KSYMBOL addr ffffffffc023cef7 len 229 type 1 flags 0x0 name bpf_prog_7be49e3934a125ba
0 0 0x5640 [0x30]: PERF_RECORD_BPF_EVENT type 1, flags 0, id 15
0 0 0x5670 [0x50]: PERF_RECORD_KSYMBOL addr ffffffffc0242837 len 229 type 1 flags 0x0 name bpf_prog_2a142ef67aaad174
0 0 0x56c0 [0x30]: PERF_RECORD_BPF_EVENT type 1, flags 0, id 16
0 0 0x56f0 [0x50]: PERF_RECORD_KSYMBOL addr ffffffffc046d593 len 229 type 1 flags 0x0 name bpf_prog_7be49e3934a125ba
0 0 0x5740 [0x30]: PERF_RECORD_BPF_EVENT type 1, flags 0, id 17
0 0 0x5770 [0x50]: PERF_RECORD_KSYMBOL addr ffffffffc046f397 len 229 type 1 flags 0x0 name bpf_prog_2a142ef67aaad174
0 0 0x57c0 [0x30]: PERF_RECORD_BPF_EVENT type 1, flags 0, id 18
0 0 0x57f0 [0x50]: PERF_RECORD_KSYMBOL addr ffffffffc0d98039 len 229 type 1 flags 0x0 name bpf_prog_7be49e3934a125ba
0 0 0x5840 [0x30]: PERF_RECORD_BPF_EVENT type 1, flags 0, id 21
0 0 0x5870 [0x50]: PERF_RECORD_KSYMBOL addr ffffffffc0d9ad98 len 229 type 1 flags 0x0 name bpf_prog_2a142ef67aaad174
0 0 0x58c0 [0x30]: PERF_RECORD_BPF_EVENT type 1, flags 0, id 22
0 0 0x58f0 [0x58]: PERF_RECORD_KSYMBOL addr ffffffffc092241b len 711 type 1 flags 0x0 name bpf_prog_2cf7fd321e9b084c_sys_enter
0 0 0x5948 [0x30]: PERF_RECORD_BPF_EVENT type 1, flags 0, id 286
0 0 0x5978 [0x58]: PERF_RECORD_KSYMBOL addr ffffffffc0b0d2d4 len 191 type 1 flags 0x0 name bpf_prog_c1bd85c092d6e4aa_sys_exit
0 0 0x59d0 [0x30]: PERF_RECORD_BPF_EVENT type 1, flags 0, id 287
[root@quaco ~]# perf evlist -v
cycles: size: 112, { sample_period, sample_freq }: 4000, sample_type: IP|TID|TIME|CPU|PERIOD, read_format: ID, disabled: 1, inherit: 1, mmap: 1, comm: 1, freq: 1, task: 1, precise_ip: 3, sample_id_all: 1, exclude_guest: 1, mmap2: 1, comm_exec: 1, ksymbol: 1, bpf_event: 1 [root@quaco ~]#
Quoted 6 lines
Quoted 3 lines
I had to add some small sleep before the
test_verifierexit, so the perf bpf thread could catch up and download the program details beforetest_verifierexited.This seems to me for a 'real' eBPF program, do we also need extra sleep so that perf bpf can save dso properly?
See abovwe.
Quoted 3 lines
BTW, I have another question: to display eBPF code, except this feature can be used by hardware tracing (e.g.
intel_pt), it also can be used by other PMU events and timer events, right?
Yeah, again, see above.
Quoted 2 lines
Thanks,
Leo Yan
Signature · 1 line
- Arnaldo
Hi Arnaldo,
On Thu, May 30, 2019 at 10:36:45AM -0300, Arnaldo Carvalho de Melo wrote:
[...]
Quoted 18 lines
One other way of testing this:
I used perf trace's use of BPF, using:
[root@quaco ~]# cat ~/.perfconfig
[llvm]
dump-obj = true
clang-opt = -g
[trace]
add_events=/home/acme/git/perf/tools/perf/examples/bpf/augmented_raw_syscalls.cshow_zeros= yes
show_duration= no
no_inherit= yes
show_timestamp= no
show_arg_names= no
args_alignment= 40
show_prefix= yes
Quoted 2 lines
For arm64 this needs fixing,
tools/perf/examples/bpf/augmented_raw_syscalls.c(its in the kernel sources) is still hard coded forx86_64syscall numbers :-\
Thanks a lot for sharing this, I will test with this method and let you and Jiri know the result in tomorrow.
[...]
Thanks,
Leo Yan
Quoted 24 lines · Leo Yan
Hi Arnaldo,
On Thu, May 30, 2019 at 10:36:45AM -0300, Arnaldo Carvalho de Melo wrote:
[...]
Quoted 18 lines
One other way of testing this:
I used perf trace's use of BPF, using:
[root@quaco ~]# cat ~/.perfconfig
[llvm]
dump-obj = true
clang-opt = -g
[trace]
add_events=/home/acme/git/perf/tools/perf/examples/bpf/augmented_raw_syscalls.cshow_zeros= yes
show_duration= no
no_inherit= yes
show_timestamp= no
show_arg_names= no
args_alignment= 40
show_prefix= yes
Quoted 5 lines
Quoted 2 lines
For arm64 this needs fixing,
tools/perf/examples/bpf/augmented_raw_syscalls.c(its in the kernel sources) is still hard coded forx86_64syscall numbers :-\Thanks a lot for sharing this, I will test with this method and let you and Jiri know the result in tomorrow.
it's always battle of having too much data but caturing everything, versus having reasonable data size and being lucky to hit the trace ;-)
with sampling on high freq and 1 second trace in another terminal I got the trace below:
jirka
---
terminal 1:
# sampleip -F 1000 20
terminal2:
# perf-with-kcore record pt -e intel_pt//k -m100M,100M -C 1 -- sleep 1
# perf-with-kcore script pt --call-trace
...
swapper 0 [001] 85820.051207146: ([kernel.kallsyms] ) __perf_event_overflow
swapper 0 [001] 85820.051207146: ([kernel.kallsyms] ) __perf_event_account_interrupt
swapper 0 [001] 85820.051207146: ([kernel.kallsyms] ) __x86_indirect_thunk_rax
swapper 0 [001] 85820.051207146: ([kernel.kallsyms] ) __x86_indirect_thunk_rax
swapper 0 [001] 85820.051207146: ([kernel.kallsyms] ) __x86_indirect_thunk_rax
swapper 0 [001] 85820.051207146: ([kernel.kallsyms] ) __x86_indirect_thunk_rax
swapper 0 [001] 85820.051207467: (bpf_prog_19578a12836c4115 ) __htab_map_lookup_elem
swapper 0 [001] 85820.051207788: ([kernel.kallsyms] ) memcmp
...
# perf-with-kcore script pt --insn-trace --xed
...
swapper 0 [001] 85820.051207467: ffffffff90c00c40 __x86_indirect_thunk_rax+0x10 ([kernel.kallsyms]) retq
swapper 0 [001] 85820.051207467: ffffffffc0557710 bpf_prog_19578a12836c4115+0x0 (bpf_prog_19578a12836c4115) pushq %rbp
swapper 0 [001] 85820.051207467: ffffffffc0557711 bpf_prog_19578a12836c4115+0x1 (bpf_prog_19578a12836c4115) mov %rsp, %rbp
swapper 0 [001] 85820.051207467: ffffffffc0557714 bpf_prog_19578a12836c4115+0x4 (bpf_prog_19578a12836c4115) sub $0x38, %rsp
swapper 0 [001] 85820.051207467: ffffffffc055771b bpf_prog_19578a12836c4115+0xb (bpf_prog_19578a12836c4115) sub $0x28, %rbp
swapper 0 [001] 85820.051207467: ffffffffc055771f bpf_prog_19578a12836c4115+0xf (bpf_prog_19578a12836c4115) movq %rbx, (%rbp)
swapper 0 [001] 85820.051207467: ffffffffc0557723 bpf_prog_19578a12836c4115+0x13 (bpf_prog_19578a12836c4115) movq %r13, 0x8(%rbp)
swapper 0 [001] 85820.051207467: ffffffffc0557727 bpf_prog_19578a12836c4115+0x17 (bpf_prog_19578a12836c4115) movq %r14, 0x10(%rbp)
swapper 0 [001] 85820.051207467: ffffffffc055772b bpf_prog_19578a12836c4115+0x1b (bpf_prog_19578a12836c4115) movq %r15, 0x18(%rbp)
swapper 0 [001] 85820.051207467: ffffffffc055772f bpf_prog_19578a12836c4115+0x1f (bpf_prog_19578a12836c4115) xor %eax, %eax
swapper 0 [001] 85820.051207467: ffffffffc0557731 bpf_prog_19578a12836c4115+0x21 (bpf_prog_19578a12836c4115) movq %rax, 0x20(%rbp)
swapper 0 [001] 85820.051207467: ffffffffc0557735 bpf_prog_19578a12836c4115+0x25 (bpf_prog_19578a12836c4115) mov $0x1, %esi
swapper 0 [001] 85820.051207467: ffffffffc055773a bpf_prog_19578a12836c4115+0x2a (bpf_prog_19578a12836c4115) movl %esi, -0xc(%rbp)
swapper 0 [001] 85820.051207467: ffffffffc055773d bpf_prog_19578a12836c4115+0x2d (bpf_prog_19578a12836c4115) movq (%rdi), %rdi
swapper 0 [001] 85820.051207467: ffffffffc0557741 bpf_prog_19578a12836c4115+0x31 (bpf_prog_19578a12836c4115) movq 0x80(%rdi), %rdi
swapper 0 [001] 85820.051207467: ffffffffc0557748 bpf_prog_19578a12836c4115+0x38 (bpf_prog_19578a12836c4115) movq %rdi, -0x8(%rbp)
swapper 0 [001] 85820.051207467: ffffffffc055774c bpf_prog_19578a12836c4115+0x3c (bpf_prog_19578a12836c4115) mov %rbp, %rsi
swapper 0 [001] 85820.051207467: ffffffffc055774f bpf_prog_19578a12836c4115+0x3f (bpf_prog_19578a12836c4115) add $0xfffffffffffffff8, %rsi
swapper 0 [001] 85820.051207467: ffffffffc0557753 bpf_prog_19578a12836c4115+0x43 (bpf_prog_19578a12836c4115) mov $0xffff9ac0b2926000, %rdi
swapper 0 [001] 85820.051207467: ffffffffc055775d bpf_prog_19578a12836c4115+0x4d (bpf_prog_19578a12836c4115) callq 0xffffffff901fde70
swapper 0 [001] 85820.051207467: ffffffff901fde70 __htab_map_lookup_elem+0x0 ([kernel.kallsyms]) nopl %eax, (%rax,%rax,1)
swapper 0 [001] 85820.051207467: ffffffff901fde75 __htab_map_lookup_elem+0x5 ([kernel.kallsyms]) pushq %rbx
swapper 0 [001] 85820.051207467: ffffffff901fde76 __htab_map_lookup_elem+0x6 ([kernel.kallsyms]) movl 0x1c(%rdi), %r9d
swapper 0 [001] 85820.051207467: ffffffff901fde7a __htab_map_lookup_elem+0xa ([kernel.kallsyms]) mov %rsi, %rdx
swapper 0 [001] 85820.051207467: ffffffff901fde7d __htab_map_lookup_elem+0xd ([kernel.kallsyms]) movl 0x214(%rdi), %ecx
swapper 0 [001] 85820.051207467: ffffffff901fde83 __htab_map_lookup_elem+0x13 ([kernel.kallsyms]) mov %rdx, %r10
swapper 0 [001] 85820.051207467: ffffffff901fde86 __htab_map_lookup_elem+0x16 ([kernel.kallsyms]) mov %r9d, %r8d
swapper 0 [001] 85820.051207467: ffffffff901fde89 __htab_map_lookup_elem+0x19 ([kernel.kallsyms]) add %r9d, %ecx
swapper 0 [001] 85820.051207467: ffffffff901fde8c __htab_map_lookup_elem+0x1c ([kernel.kallsyms]) leal -0x21524111(%rcx), %ebx
swapper 0 [001] 85820.051207467: ffffffff901fde92 __htab_map_lookup_elem+0x22 ([kernel.kallsyms]) mov %ebx, %esi
...Quoted 28 lines · Jiri Olsa
Quoted 27 lines · Leo Yan
Hi Arnaldo,
On Thu, May 30, 2019 at 10:36:45AM -0300, Arnaldo Carvalho de Melo wrote:
[...]
Quoted 20 lines
One other way of testing this:
I used perf trace's use of BPF, using:
[root@quaco ~]# cat ~/.perfconfig
[llvm]
dump-obj = true
clang-opt = -g
[trace]
add_events=/home/acme/git/perf/tools/perf/examples/bpf/augmented_raw_syscalls.cshow_zeros= yes
show_duration= no
no_inherit= yes
show_timestamp= no
show_arg_names= no
args_alignment= 40
show_prefix= yesFor arm64 this needs fixing,
tools/perf/examples/bpf/augmented_raw_syscalls.c(its in the kernel sources) is still hard coded forx86_64syscall numbers :-\
Quoted 8 lines
Quoted 2 lines
Thanks a lot for sharing this, I will test with this method and let you and Jiri know the result in tomorrow.
it's always battle of having too much data but caturing everything, versus having reasonable data size and being lucky to hit the trace ;-)
with sampling on high freq and 1 second trace in another terminal I got the trace below:
Thanks a lot for confirmation, Jiri.
I tries multiple times with different frequency for sampleip command, but still no luck to capture eBPF object info in perf data. Will dig into it and will keep you posted for this.
Thanks,
Leo Yan
Quoted 50 lines
---
terminal 1:# sampleip -F 1000 20terminal2:
# perf-with-kcore record pt -e intel_pt//k -m100M,100M -C 1 -- sleep 1 # perf-with-kcore script pt --call-trace ... swapper 0 [001] 85820.051207146: ([kernel.kallsyms] ) __perf_event_overflow swapper 0 [001] 85820.051207146: ([kernel.kallsyms] ) __perf_event_account_interrupt swapper 0 [001] 85820.051207146: ([kernel.kallsyms] ) __x86_indirect_thunk_rax swapper 0 [001] 85820.051207146: ([kernel.kallsyms] ) __x86_indirect_thunk_rax swapper 0 [001] 85820.051207146: ([kernel.kallsyms] ) __x86_indirect_thunk_rax swapper 0 [001] 85820.051207146: ([kernel.kallsyms] ) __x86_indirect_thunk_rax swapper 0 [001] 85820.051207467: (bpf_prog_19578a12836c4115 ) __htab_map_lookup_elem swapper 0 [001] 85820.051207788: ([kernel.kallsyms] ) memcmp ... # perf-with-kcore script pt --insn-trace --xed ... swapper 0 [001] 85820.051207467: ffffffff90c00c40 __x86_indirect_thunk_rax+0x10 ([kernel.kallsyms]) retq swapper 0 [001] 85820.051207467: ffffffffc0557710 bpf_prog_19578a12836c4115+0x0 (bpf_prog_19578a12836c4115) pushq %rbp swapper 0 [001] 85820.051207467: ffffffffc0557711 bpf_prog_19578a12836c4115+0x1 (bpf_prog_19578a12836c4115) mov %rsp, %rbp swapper 0 [001] 85820.051207467: ffffffffc0557714 bpf_prog_19578a12836c4115+0x4 (bpf_prog_19578a12836c4115) sub $0x38, %rsp swapper 0 [001] 85820.051207467: ffffffffc055771b bpf_prog_19578a12836c4115+0xb (bpf_prog_19578a12836c4115) sub $0x28, %rbp swapper 0 [001] 85820.051207467: ffffffffc055771f bpf_prog_19578a12836c4115+0xf (bpf_prog_19578a12836c4115) movq %rbx, (%rbp) swapper 0 [001] 85820.051207467: ffffffffc0557723 bpf_prog_19578a12836c4115+0x13 (bpf_prog_19578a12836c4115) movq %r13, 0x8(%rbp) swapper 0 [001] 85820.051207467: ffffffffc0557727 bpf_prog_19578a12836c4115+0x17 (bpf_prog_19578a12836c4115) movq %r14, 0x10(%rbp) swapper 0 [001] 85820.051207467: ffffffffc055772b bpf_prog_19578a12836c4115+0x1b (bpf_prog_19578a12836c4115) movq %r15, 0x18(%rbp) swapper 0 [001] 85820.051207467: ffffffffc055772f bpf_prog_19578a12836c4115+0x1f (bpf_prog_19578a12836c4115) xor %eax, %eax swapper 0 [001] 85820.051207467: ffffffffc0557731 bpf_prog_19578a12836c4115+0x21 (bpf_prog_19578a12836c4115) movq %rax, 0x20(%rbp) swapper 0 [001] 85820.051207467: ffffffffc0557735 bpf_prog_19578a12836c4115+0x25 (bpf_prog_19578a12836c4115) mov $0x1, %esi swapper 0 [001] 85820.051207467: ffffffffc055773a bpf_prog_19578a12836c4115+0x2a (bpf_prog_19578a12836c4115) movl %esi, -0xc(%rbp) swapper 0 [001] 85820.051207467: ffffffffc055773d bpf_prog_19578a12836c4115+0x2d (bpf_prog_19578a12836c4115) movq (%rdi), %rdi swapper 0 [001] 85820.051207467: ffffffffc0557741 bpf_prog_19578a12836c4115+0x31 (bpf_prog_19578a12836c4115) movq 0x80(%rdi), %rdi swapper 0 [001] 85820.051207467: ffffffffc0557748 bpf_prog_19578a12836c4115+0x38 (bpf_prog_19578a12836c4115) movq %rdi, -0x8(%rbp) swapper 0 [001] 85820.051207467: ffffffffc055774c bpf_prog_19578a12836c4115+0x3c (bpf_prog_19578a12836c4115) mov %rbp, %rsi swapper 0 [001] 85820.051207467: ffffffffc055774f bpf_prog_19578a12836c4115+0x3f (bpf_prog_19578a12836c4115) add $0xfffffffffffffff8, %rsi swapper 0 [001] 85820.051207467: ffffffffc0557753 bpf_prog_19578a12836c4115+0x43 (bpf_prog_19578a12836c4115) mov $0xffff9ac0b2926000, %rdi swapper 0 [001] 85820.051207467: ffffffffc055775d bpf_prog_19578a12836c4115+0x4d (bpf_prog_19578a12836c4115) callq 0xffffffff901fde70 swapper 0 [001] 85820.051207467: ffffffff901fde70 __htab_map_lookup_elem+0x0 ([kernel.kallsyms]) nopl %eax, (%rax,%rax,1) swapper 0 [001] 85820.051207467: ffffffff901fde75 __htab_map_lookup_elem+0x5 ([kernel.kallsyms]) pushq %rbx swapper 0 [001] 85820.051207467: ffffffff901fde76 __htab_map_lookup_elem+0x6 ([kernel.kallsyms]) movl 0x1c(%rdi), %r9d swapper 0 [001] 85820.051207467: ffffffff901fde7a __htab_map_lookup_elem+0xa ([kernel.kallsyms]) mov %rsi, %rdx swapper 0 [001] 85820.051207467: ffffffff901fde7d __htab_map_lookup_elem+0xd ([kernel.kallsyms]) movl 0x214(%rdi), %ecx swapper 0 [001] 85820.051207467: ffffffff901fde83 __htab_map_lookup_elem+0x13 ([kernel.kallsyms]) mov %rdx, %r10 swapper 0 [001] 85820.051207467: ffffffff901fde86 __htab_map_lookup_elem+0x16 ([kernel.kallsyms]) mov %r9d, %r8d swapper 0 [001] 85820.051207467: ffffffff901fde89 __htab_map_lookup_elem+0x19 ([kernel.kallsyms]) add %r9d, %ecx swapper 0 [001] 85820.051207467: ffffffff901fde8c __htab_map_lookup_elem+0x1c ([kernel.kallsyms]) leal -0x21524111(%rcx), %ebx swapper 0 [001] 85820.051207467: ffffffff901fde92 __htab_map_lookup_elem+0x22 ([kernel.kallsyms]) mov %ebx, %esi ...
Hi Arnaldo,
On Thu, May 30, 2019 at 10:36:45AM -0300, Arnaldo Carvalho de Melo wrote:
[...]
Quoted 18 lines
One other way of testing this:
I used perf trace's use of BPF, using:
[root@quaco ~]# cat ~/.perfconfig
[llvm]
dump-obj = true
clang-opt = -g
[trace]
add_events=/home/acme/git/perf/tools/perf/examples/bpf/augmented_raw_syscalls.cshow_zeros= yes
show_duration= no
no_inherit= yes
show_timestamp= no
show_arg_names= no
args_alignment= 40
show_prefix= yes
Quoted 2 lines
For arm64 this needs fixing,
tools/perf/examples/bpf/augmented_raw_syscalls.c(its in the kernel sources) is still hard coded forx86_64syscall numbers :-\
I changed the system call numbers for arm64 respectively in augmented_raw_syscalls.s; so this if fine.
Quoted 4 lines
Use some other BPF workload, one that has its programs being hit so that we get samples in it, in my case running:
# perf trace
After I run 'perf trace' command it reports the building failure when generate eBPF object file, as shown in below log. I saw the eBPF code includes the header files unistd.h and pid_filter.h which cannot be found when clang compiled it.
These two header files are stored in the folder $linux/tools/perf/include/bpf so I tried to use below command to specify header path, but still failed:
# clang-7 -target bpf -O2 -I./include/bpf -I./include \ -I../../usr/include -I../../include \ -I../../tools/testing/selftests/bpf/ \ -I../../tools/lib/ \ -c examples/bpf/augmented_raw_syscalls.c
So now I am stuck for eBPF program building. Do I miss some configurations for headers pathes for llvm/clang?
BTW, I notice another potential issue is even the eBPF bytecode building failed, 'perf trace' command still can continue its work; after read the code [1], the flow is:
trace__config();
`-> parse_events_option();When building eBPF object failure, parse_events_option() returns 1; for this case trace__config() needs to detect the erro and return -1 rather than directly return 1 to caller function.
---8<---
# perf trace
/mnt/linux-kernel/linux-cs-dev/tools/perf/examples/bpf/augmented_raw_syscalls.c:17:10: fatal error: 'unistd.h' file not found
#include <unistd.h>
^~~~~~~~~~
1 error generated.
ERROR: unable to compile /mnt/linux-kernel/linux-cs-dev/tools/perf/examples/bpf/augmented_raw_syscalls.c
Hint: Check error message shown above.
Hint: You can also pre-compile it into .o using:
clang -target bpf -O2 -c /mnt/linux-kernel/linux-cs-dev/tools/perf/examples/bpf/augmented_raw_syscalls.c
with proper -I and -D options.
event syntax error: '/mnt/linux-kernel/linux-cs-dev/tools/perf/examples/bpf/augmented_raw_syscalls.c'
\___ Failed to load /mnt/linux-kernel/linux-cs-dev/tools/perf/examples/bpf/augmented_raw_syscalls.c from source: Error when compiling BPF scriptlet(add -v to see detail)
Run 'perf list' for a list of valid events
Thanks a lot for help!