From: Eric Saint-Etienne <eric.saint.etienne@oracle.com>
To: Linux Kernel <linux-kernel@vger.kernel.org>
Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>,
Arnaldo Carvalho de Melo <acme@kernel.org>,
Ingo Molnar <mingo@redhat.com>, Jiri Olsa <jolsa@redhat.com>,
Peter Zijlstra <peterz@infradead.org>,
Namhyung Kim <namhyung@kernel.org>,
Darren Kenny <darren.kenny@oracle.com>,
Eric Saint-Etienne <eric.saintetienne@gmail.com>
Subject: [PATCH UEK5] perf symbols: Cannot disassemble some routines when debuginfo present
Date: Wed, 12 Dec 2018 08:39:01 -0800 [thread overview]
Message-ID: <1544632741-5556-1-git-send-email-eric.saint.etienne@oracle.com> (raw)
When the kernel is compiled with -ffunction-sections and perf uses the kernel
debuginfo, perf fails the very first symbol lookup and ends up with an offset
in [kernel.vmlinux]. It's due to how perf loads the .text map first then loads
the other maps in the kernel debuginfo image.
This issue is specific to the debuginfo when using -ffunction-sections and it
doesn't happen with kallsyms because there's not multiple stages of loading
/proc/kallsyms.
This patch makes sure that the event address we're looking up is indeed within
the map we've found, otherwise we look another map up again. Only one extra
lookup at most is required for the proper map to be found, if it exists.
Orabug: 28543586
Reviewed-by: Eric Saint-Etienne <eric.saint.etienne@oracle.com>
---
tools/perf/util/event.c | 13 +++++++++++++
1 file changed, 13 insertions(+)
diff --git a/tools/perf/util/event.c b/tools/perf/util/event.c
index fc690fe..1fbbaf1 100644
--- a/tools/perf/util/event.c
+++ b/tools/perf/util/event.c
@@ -1447,6 +1447,19 @@ void thread__find_addr_map(struct thread *thread, u8 cpumode,
*/
if (load_map)
map__load(al->map);
+
+ /*
+ * Sometimes we find the wrong map: one whose end address is
+ * ~0ULL, in particular when map__load() set a proper end
+ * address for the map we're considering.
+ *
+ * So we make sure that it's actually the right map that we've
+ * found, and if not, we try again and within at most one
+ * attempt we'll get the right map, if it exists.
+ */
+ if (al->addr < al->map->start || al->addr >= al->map->end)
+ goto try_again;
+
al->addr = al->map->map_ip(al->map, al->addr);
}
}
--
1.8.3.1
reply other threads:[~2018-12-12 16:11 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
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=1544632741-5556-1-git-send-email-eric.saint.etienne@oracle.com \
--to=eric.saint.etienne@oracle.com \
--cc=acme@kernel.org \
--cc=alexander.shishkin@linux.intel.com \
--cc=darren.kenny@oracle.com \
--cc=eric.saintetienne@gmail.com \
--cc=jolsa@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=namhyung@kernel.org \
--cc=peterz@infradead.org \
/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
all inboxes | Powered by JetHome®