linux-perf-users.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Arnaldo Carvalho de Melo <acme@kernel.org>
To: Thomas-Mich Richter <tmricht@linux.vnet.ibm.com>
Cc: "linux-perf-use." <linux-perf-users@vger.kernel.org>,
	Hendrik Brueckner <brueckner@linux.vnet.ibm.com>,
	Zvonko Kosic <zvonko.kosic@de.ibm.com>,
	Adrian Hunter <adrian.hunter@intel.com>,
	Andi Kleen <ak@linux.intel.com>, Jiri Olsa <jolsa@kernel.org>,
	Michael Ellerman <mpe@ellerman.id.au>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>
Subject: Re: perf report does not resolve symbols on s390x
Date: Tue, 11 Jul 2017 16:48:53 -0300	[thread overview]
Message-ID: <20170711194853.GJ27350@kernel.org> (raw)
In-Reply-To: <20170711193828.GI27350@kernel.org>

Em Tue, Jul 11, 2017 at 04:38:28PM -0300, Arnaldo Carvalho de Melo escreveu:
> Em Tue, Jul 11, 2017 at 04:03:04PM -0300, Arnaldo Carvalho de Melo escreveu:
> > Em Fri, Jul 07, 2017 at 02:17:25PM +0200, Thomas-Mich Richter escreveu:
> > > On 07/06/2017 02:35 PM, Thomas-Mich Richter wrote:
> > > It determines the kernel starts at address 1<<63 and loads the kernel address mapping.
> > > On s390x
> > > - The kernel starts at 0x0 (value of map->start) and thus all checks in function 
> > >   thread__find_addr_map() fail and no symbol is found for the specified addresses
> > >   because the kernel starts at 0x8000000000000000. Which is wrong the kernel start at 0x0.

> > Hi Thomas, really nice debugging session!

> > I'm trying the one-liner below, Adrian, can you please check this and
> > provide an ack? I think that that comment about the address that it will
> > default when map__load() fails needs rewriting in light of Thomas
> > comments about other arches (see further below)?

> > I did a quick check of machine->kernel_start usage in Intel PT and since
> > on x86 that assumption about partitioning the address space holds, no
> > problem should be introduced by the one-liner fix, right?
 
> Argh, this is also broken:
 
> static inline bool machine__kernel_ip(struct machine *machine, u64 ip)
> {
>         u64 kernel_start = machine__kernel_start(machine);
> 
>         return ip >= kernel_start;
> }
> 
> We can't judge if a address is in the kernel like that :-\

So, this is used by:

[acme@jouet linux]$ find tools/ -name "*.[ch]" | xargs grep -w machine__kernel_ip
tools/perf/builtin-script.c:	kernel = machine__kernel_ip(machine, start);
tools/perf/builtin-script.c:	if (kernel != machine__kernel_ip(machine, end)) {

That is just for "brstackinsn", would that make sense for Sparc, S/390?

tools/perf/util/intel-bts.c:	if (machine__kernel_ip(machine, ip))
tools/perf/util/intel-bts.c:		if (!machine__kernel_ip(btsq->bts->machine, branch->from) &&
tools/perf/util/intel-bts.c:		    machine__kernel_ip(btsq->bts->machine, branch->to) &&

Intel specific stuff, so should be ok.

tools/perf/util/event.c:		    machine__kernel_ip(machine, al->addr)) {

For this last one, that affects all arches, I think we can just remove
this check and look at the kernel when not finding it anywhere else?

diff --git a/tools/perf/util/event.c b/tools/perf/util/event.c
index dc5c3bb69d73..8e435baaae6a 100644
--- a/tools/perf/util/event.c
+++ b/tools/perf/util/event.c
@@ -1432,8 +1432,7 @@ void thread__find_addr_map(struct thread *thread, u8 cpumode,
 		 * in the whole kernel symbol list.
 		 */
 		if (cpumode == PERF_RECORD_MISC_USER && machine &&
-		    mg != &machine->kmaps &&
-		    machine__kernel_ip(machine, al->addr)) {
+		    mg != &machine->kmaps) {
 			mg = &machine->kmaps;
 			load_map = true;
 			goto try_again;

> > > This raises 2 questions:
> > > 1. s390 has a 64 bit address space for user and kernel. The processor status word (PSW)
> > >    determines which address space to use. That requires the PSW in the sample. Not sure
> > >    this is the case?
> > > 2. How does this work on sparc and other architectures with the same addressing scheme?
> > >
> > > Thanks.
> > > --
> > > Thomas Richter, Dept 3303, IBM LTC Boeblingen Germany

  reply	other threads:[~2017-07-11 19:48 UTC|newest]

Thread overview: 14+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-07-05 14:45 perf report does not resolve symbols on s390x Thomas-Mich Richter
2017-07-05 15:50 ` Arnaldo Carvalho de Melo
2017-07-06  7:23   ` Thomas-Mich Richter
2017-07-06 12:35   ` Thomas-Mich Richter
2017-07-07 12:17     ` Thomas-Mich Richter
2017-07-07 12:22       ` Arnaldo Carvalho de Melo
2017-07-11 19:03       ` Arnaldo Carvalho de Melo
2017-07-11 19:38         ` Arnaldo Carvalho de Melo
2017-07-11 19:48           ` Arnaldo Carvalho de Melo [this message]
2017-07-12  8:21             ` Thomas-Mich Richter
2017-07-12 10:40             ` Michael Ellerman
2017-07-12 14:04               ` Arnaldo Carvalho de Melo
2017-07-13 12:02                 ` Michael Ellerman
2017-07-12  9:05         ` Thomas-Mich Richter

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20170711194853.GJ27350@kernel.org \
    --to=acme@kernel.org \
    --cc=adrian.hunter@intel.com \
    --cc=ak@linux.intel.com \
    --cc=brueckner@linux.vnet.ibm.com \
    --cc=jolsa@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-perf-users@vger.kernel.org \
    --cc=mpe@ellerman.id.au \
    --cc=tmricht@linux.vnet.ibm.com \
    --cc=zvonko.kosic@de.ibm.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).