Am Dienstag, 29 März 2016, 14:31:34 schrieb Michael Ellerman: > On Mon, 2016-03-28 at 17:06 -0300, Thiago Jung Bauermann wrote: > > With this patch, all vmlinux symbols match /proc/kallsyms and the > > testcase passes. > > Have you tested this on an LE system?
No, I was focusing on ppc64 BE. > I did a quick test and it appears to > be completely broken. Basically every symbol is not found, eg: > > 1: vmlinux symtab matches kallsyms : > --- start --- > test child forked, pid 16222 > Using /proc/kcore for kernel object code > Looking at the vmlinux_path (8 entries long) > Using /boot/vmlinux-4.5.0-11318-gdf01bc5cf4ea for symbols > 0xc00000000000b428: run_init_process not on kallsyms > 0xc00000000000b478: try_to_run_init_process not on kallsyms > 0xc00000000000b4f8: do_one_initcall not on kallsyms > 0xc00000000000b768: match_dev_by_uuid not on kallsyms > ... > 0xc0000000009846b8: write_mem not on kallsyms > 0xc000000000984728: do_fp_store not on kallsyms > 0xc000000000984828: emulate_step not on kallsyms > > $ sudo grep emulate_step /proc/kallsyms > c000000000984820 T emulate_step > > > Notice it's off by 8. That's because of the local/global entry point on > LE. So that will need to be fixed somewhere. Symbols loaded from the vmlinux file get adjusted to the local entry point because symbol-elf.c:dso__load_sym calls arch__elf_sym_adjust for each function symbol, which on ppc64le adjusts the address to the local entry point. On the other hand, when symbols are loaded from /proc/kallsyms they are used as-is (i.e., with the global entry point address). This seems inconsistent: dso__load_kernel_sym can end up loading symbols from either vmlinux or /proc/kallsyms, so it seems symbols should look the same wherever they are loaded from. I am still trying to understand what the rest of the perf code expects. If I comment out the call to arch__elf_sym_adjust in dso__load_sym, then all symbols are found in the vmlinux-kallsyms.c test (the test still fails because two symbols have different names. I haven’t checked why). Also, the code-reading.c test is able to read object code for a lot (but not all) of the sample events, whereas in the adjusted symbols case it can’t read object code for any sample event. The other perf tests are unaffected by the change. I thought that if there’s no vmlinux available, then perf would have to rely only on /proc/kallsyms and I would see some difference in the test results compared to when perf uses vmlinux and adjusts the symbols to the local entry point, but I saw no difference at all. So at first glance, it looks like perf is better off using symbols that point to the global entry point... -- []'s Thiago Jung Bauermann IBM Linux Technology Center _______________________________________________ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev