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