Searched hist:"67 fd1892" (Results 1 – 5 of 5) sorted by relevance
/openbmc/linux/tools/perf/util/ |
H A D | dsos.c | 67fd1892 Wed Feb 02 01:08:26 CST 2022 Namhyung Kim <namhyung@kernel.org> perf tools: Try chroot'ed filename when opening dso/symbol
Currently it doesn't handle tasks in chroot properly. As filenames in MMAP records base on their root directory, it's different than what perf tool can see from outside.
Add filename_with_chroot() helper to deal with those cases. The function returns a new filename only if it's in a different root directory. Since it needs to access /proc for the process, it only works until the task exits.
With this change, I can see symbols in my program like below.
# perf record -o- chroot myroot myprog 3 | perf report -i- ... # # Overhead Command Shared Object Symbol # ........ ....... ................. ............................. # 99.83% myprog myprog [.] loop 0.04% chroot [kernel.kallsyms] [k] fxregs_fixup 0.04% chroot [kernel.kallsyms] [k] rsm_load_seg_32 ...
Signed-off-by: Namhyung Kim <namhyung@kernel.org> Acked-by: Jiri Olsa <jolsa@kernel.org> Cc: Andi Kleen <ak@linux.intel.com> Cc: Ian Rogers <irogers@google.com> Cc: Peter Zijlstra <peterz@infradead.org> Link: http://lore.kernel.org/lkml/20220202070828.143303-3-namhyung@kernel.org Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
|
H A D | util.c | 67fd1892 Wed Feb 02 01:08:26 CST 2022 Namhyung Kim <namhyung@kernel.org> perf tools: Try chroot'ed filename when opening dso/symbol
Currently it doesn't handle tasks in chroot properly. As filenames in MMAP records base on their root directory, it's different than what perf tool can see from outside.
Add filename_with_chroot() helper to deal with those cases. The function returns a new filename only if it's in a different root directory. Since it needs to access /proc for the process, it only works until the task exits.
With this change, I can see symbols in my program like below.
# perf record -o- chroot myroot myprog 3 | perf report -i- ... # # Overhead Command Shared Object Symbol # ........ ....... ................. ............................. # 99.83% myprog myprog [.] loop 0.04% chroot [kernel.kallsyms] [k] fxregs_fixup 0.04% chroot [kernel.kallsyms] [k] rsm_load_seg_32 ...
Signed-off-by: Namhyung Kim <namhyung@kernel.org> Acked-by: Jiri Olsa <jolsa@kernel.org> Cc: Andi Kleen <ak@linux.intel.com> Cc: Ian Rogers <irogers@google.com> Cc: Peter Zijlstra <peterz@infradead.org> Link: http://lore.kernel.org/lkml/20220202070828.143303-3-namhyung@kernel.org Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
|
H A D | dso.c | 67fd1892 Wed Feb 02 01:08:26 CST 2022 Namhyung Kim <namhyung@kernel.org> perf tools: Try chroot'ed filename when opening dso/symbol
Currently it doesn't handle tasks in chroot properly. As filenames in MMAP records base on their root directory, it's different than what perf tool can see from outside.
Add filename_with_chroot() helper to deal with those cases. The function returns a new filename only if it's in a different root directory. Since it needs to access /proc for the process, it only works until the task exits.
With this change, I can see symbols in my program like below.
# perf record -o- chroot myroot myprog 3 | perf report -i- ... # # Overhead Command Shared Object Symbol # ........ ....... ................. ............................. # 99.83% myprog myprog [.] loop 0.04% chroot [kernel.kallsyms] [k] fxregs_fixup 0.04% chroot [kernel.kallsyms] [k] rsm_load_seg_32 ...
Signed-off-by: Namhyung Kim <namhyung@kernel.org> Acked-by: Jiri Olsa <jolsa@kernel.org> Cc: Andi Kleen <ak@linux.intel.com> Cc: Ian Rogers <irogers@google.com> Cc: Peter Zijlstra <peterz@infradead.org> Link: http://lore.kernel.org/lkml/20220202070828.143303-3-namhyung@kernel.org Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
|
H A D | util.h | 67fd1892 Wed Feb 02 01:08:26 CST 2022 Namhyung Kim <namhyung@kernel.org> perf tools: Try chroot'ed filename when opening dso/symbol
Currently it doesn't handle tasks in chroot properly. As filenames in MMAP records base on their root directory, it's different than what perf tool can see from outside.
Add filename_with_chroot() helper to deal with those cases. The function returns a new filename only if it's in a different root directory. Since it needs to access /proc for the process, it only works until the task exits.
With this change, I can see symbols in my program like below.
# perf record -o- chroot myroot myprog 3 | perf report -i- ... # # Overhead Command Shared Object Symbol # ........ ....... ................. ............................. # 99.83% myprog myprog [.] loop 0.04% chroot [kernel.kallsyms] [k] fxregs_fixup 0.04% chroot [kernel.kallsyms] [k] rsm_load_seg_32 ...
Signed-off-by: Namhyung Kim <namhyung@kernel.org> Acked-by: Jiri Olsa <jolsa@kernel.org> Cc: Andi Kleen <ak@linux.intel.com> Cc: Ian Rogers <irogers@google.com> Cc: Peter Zijlstra <peterz@infradead.org> Link: http://lore.kernel.org/lkml/20220202070828.143303-3-namhyung@kernel.org Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
|
H A D | symbol.c | 67fd1892 Wed Feb 02 01:08:26 CST 2022 Namhyung Kim <namhyung@kernel.org> perf tools: Try chroot'ed filename when opening dso/symbol
Currently it doesn't handle tasks in chroot properly. As filenames in MMAP records base on their root directory, it's different than what perf tool can see from outside.
Add filename_with_chroot() helper to deal with those cases. The function returns a new filename only if it's in a different root directory. Since it needs to access /proc for the process, it only works until the task exits.
With this change, I can see symbols in my program like below.
# perf record -o- chroot myroot myprog 3 | perf report -i- ... # # Overhead Command Shared Object Symbol # ........ ....... ................. ............................. # 99.83% myprog myprog [.] loop 0.04% chroot [kernel.kallsyms] [k] fxregs_fixup 0.04% chroot [kernel.kallsyms] [k] rsm_load_seg_32 ...
Signed-off-by: Namhyung Kim <namhyung@kernel.org> Acked-by: Jiri Olsa <jolsa@kernel.org> Cc: Andi Kleen <ak@linux.intel.com> Cc: Ian Rogers <irogers@google.com> Cc: Peter Zijlstra <peterz@infradead.org> Link: http://lore.kernel.org/lkml/20220202070828.143303-3-namhyung@kernel.org Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
|