Re: [PATCH] Remove kretprobe_trampoline_holder.

[Thiago Jung Bauermann <bauerman@linux.vnet.ibm.com>]

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

> 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