Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Date:   Thu, 8 Nov 2018 16:51:52 +0800
From:   leo.yan@linaro.org
To:     Jiri Olsa <jolsa@redhat.com>
Cc:     acme@redhat.com, Jiri Olsa <jolsa@kernel.org>,
        Mathieu Poirier <mathieu.poirier@linaro.org>,
        Coresight ML <coresight@lists.linaro.org>,
        linux-kernel@vger.kernel.org
Subject: Re: Question: perf dso support for /proc/kallsyms
Message-ID: <20181108085152.GA1925@leoy-ThinkPad-X240s>
References: <20181102025516.GA25374@leoy-ThinkPad-X240s>
 <20181107141006.GD12870@krava>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20181107141006.GD12870@krava>
User-Agent: Mutt/1.10+31 (9cdd884) (2018-06-19)
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

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/tools/perf/util/cs-etm.c#n302

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