Re: Question: perf dso support for /proc/kallsyms

[leo.yan@linaro.org]

On Fri, Nov 02, 2018 at 02:12:28PM +0000, Al Grant wrote:
> > root@debian:~/coresight_test# perf buildid-list
> > 0242d9154c78df1d8fe1d0512c36a236d0861a18 [kernel.kallsyms]
> > b8c89e8ba41a2ea486c66a50c29c60d38c34a759 /root/coresight_test/main
> > 26b12a9d1a54ed2b0478cb0203435b76aabab3fb /usr/lib/aarch64-linux-gnu/ld-
> > 2.27.so
> > 8fca7ed524c9469b065af83bc8a529fe72858f53 [vdso]
> > 25829a59e21012cfde7850b30a310cd3a58f531c
> > /root/coresight_test/libcstest.so
> > 70512527439ef76c8802a7a2a546bde6a5a6e967 /usr/lib/aarch64-linux-
> > gnu/libc-2.27.so
> > root@debian:~/coresight_test# ls
> > ~/.debug/\[kernel.kallsyms\]/0242d9154c78df1d8fe1d0512c36a236d0861a18/
> > kallsyms
> 
> What's in that last file?

I can see the correct symbol infos in this file:

root@debian:~/coresight_test# cat ~/.debug/\[kernel.kallsyms\]/0242d9154c78df1d8fe1d0512c36a236d0861a18/kallsyms | head -20
ffff000008080000 t _head
ffff000008080000 T _text
ffff000008080040 t pe_header
ffff000008080044 t coff_header
ffff000008080058 t optional_header
ffff000008080070 t extra_header_fields
ffff0000080800f8 t section_table
ffff000008081000 T do_undefinstr
ffff000008081000 t efi_header_end
ffff000008081000 T _stext
ffff000008081000 T __exception_text_start
ffff000008081268 T do_cp15instr
ffff000008081380 T do_sysinstr
ffff000008081410 T do_debug_exception
ffff000008081550 T do_mem_abort
ffff000008081600 T do_el0_irq_bp_hardening
ffff000008081650 T do_el0_ia_bp_hardening
ffff0000080816f8 T do_sp_pc_abort
ffff0000080817c4 T __exception_text_end
ffff0000080817c8 t bcm2835_handle_irq

> I've seen it happen that the copy of kallsyms
> in ~/.debug has the symbol addresses as zeroes - possibly because it
> was created when you didn't have permissions. That's really a bug
> in perf, as cacheing a copy of this file with the addresses zeroed out
> is kind of pointless. Again, this happens on Intel too.
> 
> Then, you can give yourself permissions - but perf's already cached
> the file and won't update it!
> 
> If you delete it, and then rerun perf record (either as sudo or now
> that you've got kptr_restrict=0) you should see it reappear, with
> correct kernel addresses.
> 
> Perhaps nobody spotted this on Intel because perf report goes directly
> to /proc/kallsyms. But it would be an issue if you ran a perf report
> on a perf.data from an older kernel and it had to go to ~/.debug.
> At that point the fact that ~/.debug/[kernel.kallsyms] had zeroes would
> mean you couldn't symbolicate any addresses.

This is another issue related with permission for accessing kernel
pointer values and this will bother much for cross platforms usage
(e.g. 'perf record' on Arm platform and 'perf script' on x86
platform).

At my side, I executed all commands on Arm Juno board and simply to
say the kallsyms support is broken in perf.

Thanks,
Leo Yan