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
next prev parent 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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.