Re: [PATCH] Remove kretprobe_trampoline_holder.
From: Thiago Jung Bauermann <hidden>
Date: 2016-03-29 23:35:45
Am Dienstag, 29 M=C3=A4rz 2016, 14:31:34 schrieb Michael Ellerman:
On Mon, 2016-03-28 at 17:06 -0300, Thiago Jung Bauermann wrote:quoted
With this patch, all vmlinux symbols match /proc/kallsyms and the testcase passes.=20 Have you tested this on an LE system?
No, I was focusing on ppc64 BE.
quoted hunk ↗ jump to hunk
I did a quick test and it appears to be completely broken. Basically every symbol is not found, eg: =20 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 =20 $ sudo grep emulate_step /proc/kallsyms c000000000984820 T emulate_step =20 =20 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 po= int=20 because symbol-elf.c:dso__load_sym calls arch__elf_sym_adjust for each=20= function symbol, which on ppc64le adjusts the address to the local entr= y=20 point. On the other hand, when symbols are loaded from /proc/kallsyms t= hey=20 are used as-is (i.e., with the global entry point address). This seems inconsistent: dso__load_kernel_sym can end up loading symbol= s=20 from either vmlinux or /proc/kallsyms, so it seems symbols should look = the=20 same wherever they are loaded from. I am still trying to understand wha= t the=20 rest of the perf code expects. If I comment out the call to arch__elf_sym_adjust in dso__load_sym, the= n all=20 symbols are found in the vmlinux-kallsyms.c test (the test still fails=20= because two symbols have different names. I haven=E2=80=99t checked why= ). Also, the=20 code-reading.c test is able to read object code for a lot (but not all)= of=20 the sample events, whereas in the adjusted symbols case it can=E2=80=99= t read object=20 code for any sample event. The other perf tests are unaffected by the=20= change. I thought that if there=E2=80=99s no vmlinux available, then perf would= have to rely=20 only on /proc/kallsyms and I would see some difference in the test resu= lts=20 compared to when perf uses vmlinux and adjusts the symbols to the local= =20 entry point, but I saw no difference at all. So at first glance, it looks like perf is better off using symbols that= =20 point to the global entry point... --=20 []'s Thiago Jung Bauermann IBM Linux Technology Center