[PATCH] Remove kretprobe_trampoline_holder.

[Naveen N. Rao]

On 2016/03/29 08:35PM, Thiago Jung Bauermann wrote:
> 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.

Which kernel did you use? I don't see this with the latest 4.6.0-rc1.

> 
> > 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.

The LEP is used since probing on that catches calls to both the GEP and 
the LEP. I did fix 'perf probe' to fixup the kallsyms address as well.  
See commit 7b6ff0bdb.

> 
> 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...

See above - we need to use the LEP. I suspect we don't fixup all the 
symbols in kallsyms -- just the ones being probed which explains why 
there is a mismatch. Let me take a look.


- Naveen