Hi Mike, On Fri, Nov 02, 2018 at 01:08:40PM +0000, Mike Leach wrote: > Hi Leo, > > My understanding is that when we decode CoreSight trace - be it on the > system that generated it, or off target device on a separate host > system, we are using the dso files in .debug/ as these represent the > memory layout at the time trace was recorded. > > If I look into a recent session copied up to my linux box from DB410, > is see > ~/.debug/\[kernel.kallsyms\]/ee80c1f3a434469f6174e1cf4bb5583d83a013dc/kallsyms > - which seems to me to be the relevant symbol file to use rather than > the live one generated by /proc/kallsyms. I don't really want to use > the local /proc/kallsyms on my x86 linux box when decoding an ARM > trace captured elsewhere. > > So perhaps the problem to be solved is not how to use /proc/kallsyms > if no vmlinux is supplied to the script, but ensure that the > [kernel.kallsyms] is used?
Yes, this is good point, the subject should be changed to: "Question: perf dso support for kallsyms". I think I made a mistake in my previous email, so clarify it: ~/.debug/\[kernel.kallsyms\]/$BUILDID/kallsyms should has higher priority than /proc/kallsyms, by default the perf tool should use kallsyms file under ~/.debug folder. I also tried to manually specify the kallsyms file with the command "perf script --kallsyms ./kallsyms", for both cases perf fails to parse symbols for any kernel address. Thanks, Leo Yan