Hi Jiri,
On Wed, Nov 07, 2018 at 03:10:06PM +0100, Jiri Olsa wrote:
On Fri, Nov 02, 2018 at 10:55:16AM +0800, leo.yan@linaro.org wrote:
Hi all,
Now I found that if use the command 'perf script' for Arm CoreSight trace data, it fails to parse kernel symbols if we don't specify kernel vmlinux file. So when we don't specify kernel symbol files then perf tool will roll back to use /proc/kallsyms for kernel symbols parsing, as result it will run into below flow:
yep, AFAIK if there's no vmlinux found we fallback to /proc/kallsyms
thread__find_addr_map(thread, cpumode, MAP__FUNCTION, address, &al); map__load(al.map); dso__data_read_offset(al.map->dso, machine, offset, buffer, size); `-> data_read_offset()
so what is the actual error you see in the perf script? unresolved samples? could you please describe your config and workload?
So at my side the error is the CoreSight trace decoder fails to generate samples if the sample has kernel address, thus the decoder doesn't generate any kernel sample if use kallsyms as dso.
For more detailed info is: the CoreSight decoder needs firstly to get dso related info by calling dso__data_read_offset() [1], if we use kallsyms then this function always returns failure then this leads the docoder to discard all kernel samples.
Regarding to testing case, I can simply run 'uname' program so it can produce kernel and user space trace data, if I use 'perf script -k vmlinux' then I can see perf generate samples for kernel related traces, but if use 'perf script' then only can see samples for user space.
Thanks, Leo Yan
[1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/tool...
I can observe the function data_read_offset() returns failure, this is caused by checking the offset sanity "if (offset > dso->data.file_size)" (I pasted the whole function code at below in case you want to get more context for it), but if perf use "/proc/kallsyms" to load kernel symbols, the variable 'dso->data.file_size' will be set to zero thus the sanity checking always thinks the offset is out of the file size bound.
Now I still don't understand how the dso/map support "/proc/kallsyms" and have no idea to fix this issue, though I spent some time to look into it.
Could you give some suggestion for this? Or even better if you have fixing for this, I am glad to test at my side.
static ssize_t data_read_offset(struct dso *dso, struct machine *machine, u64 offset, u8 *data, ssize_t size) { if (data_file_size(dso, machine)) return -1;
/* Check the offset sanity. */ if (offset > dso->data.file_size) return -1; if (offset + size < offset) return -1; return cached_read(dso, machine, offset, data, size);}
Thanks, Leo Yan