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:   Fri, 9 Nov 2018 09:11:42 +0100
From:   Jiri Olsa <jolsa@redhat.com>
To:     leo.yan@linaro.org
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: <20181109081142.GH29732@krava>
References: <20181102025516.GA25374@leoy-ThinkPad-X240s>
 <20181107141006.GD12870@krava>
 <20181108085152.GA1925@leoy-ThinkPad-X240s>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20181108085152.GA1925@leoy-ThinkPad-X240s>
User-Agent: Mutt/1.10.1 (2018-07-13)
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

On Thu, Nov 08, 2018 at 04:51:52PM +0800, leo.yan@linaro.org wrote:
> 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.

I haven't checked on this code for some time but AFAICS
before you call dso__data_read_offset you need to check
  dso->data.status != DSO_DATA_STATUS_ERROR

map__load call ahead should take care on setting this and
find the source of the data

check the intel_pt code (intel_pt_walk_next_insn)
or for example grab_bb in perf script

I guess you need to have either vmlinux or kcore in place
to get some data out of it

jirka