[PATCH] Remove kretprobe_trampoline_holder.

[Thiago Jung Bauermann]

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