Date: Mon, 7 Sep 2015 19:27:01 -0700
(Please Cc me when replying; I'm not subscribed)
Hi. Perf currently has trouble reading separate debug-info files when trying to
look up symbols in a 'perf report'. According to the gdb documentation:
https://sourceware.org/gdb/onlinedocs/gdb/Separate-Debug-Files.html
separate debug-info files can live in any of
/usr/lib/debug/.build-id/ab/cdef1234.debug
/usr/bin/debuglink
/usr/bin/.debug/debuglink
/usr/lib/debug/usr/bin/debuglink
Prior to this patch series, perf reads the value of the debuglink from the
.gnu_debuglink section, and tries to read a file of that name in the same
directory as the stripped ELF file. For an executable, this would be
"/usr/bin/debuglink" above. And that's it; the other paths are not checked.
The "normal" thing to do on Debian boxes these days is
/usr/lib/debug/.build-id/ab/cdef1234.debug
This patch series makes this work. The remaining two paths are still unchecked,
but I don't know if they're "standard" anywhere
Dima Kogan (2):
perf: fixed type error when reading a build-id
perf: we can now read separate debug-info files based on a build ID
tools/perf/util/symbol-minimal.c | 2 +-
tools/perf/util/symbol.c | 9 +
2 files changed, 10 insertions(+), 1 deletion(-)
--
2.1.4
>From b095f63f4bcfeb9c00f62a7627243c5231e4d666 Mon Sep 17 00:00:00 2001
From: Dima Kogan
Date: Mon, 7 Sep 2015 17:30:28 -0700
Subject: [PATCH 1/2] perf: fixed type error when reading a build-id
This was benign, but wrong. The build-id should live in a char[], not a char*[]
Signed-off-by: Dima Kogan
---
tools/perf/util/symbol-minimal.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/tools/perf/util/symbol-minimal.c b/tools/perf/util/symbol-minimal.c
index fd8477c..4890633 100644
--- a/tools/perf/util/symbol-minimal.c
+++ b/tools/perf/util/symbol-minimal.c
@@ -337,7 +337,7 @@ int dso__load_sym(struct dso *dso, struct map *map __maybe_unused,
symbol_filter_t filter __maybe_unused,
int kmodule __maybe_unused)
{
- unsigned char *build_id[BUILD_ID_SIZE];
+ unsigned char build_id[BUILD_ID_SIZE];
int ret;
ret = fd__is_64_bit(ss->fd);
--
2.1.4
>From 956877b14b0243868cbf381f0fc5607eb973f268 Mon Sep 17 00:00:00 2001
From: Dima Kogan
Date: Mon, 7 Sep 2015 17:34:19 -0700
Subject: [PATCH 2/2] perf: we can now read separate debug-info files based on
a build ID
Recent GDB (at least on a vanilla Debian box) looks for debug information in
/usr/lib/debug/.build-id/nn/nnn
where nn/nn is the build-id of the stripped ELF binary. This is documented
here:
https://sourceware.org/gdb/onlinedocs/gdb/Separate-Debug-Files.html
This was not working in perf because we didn't read the build id until AFTER we
searched for the separate debug information file. This patch reads the build ID
and THEN does the search.
Signed-off-by: Dima Kogan
---
tools/perf/util/symbol.c | 9 +
1 file changed, 9 insertions(+)
diff --git a/tools/perf/util/symbol.c b/tools/perf/util/symbol.c
index 1f97ffb..05c656b 100644
--- a/tools/perf/util/symbol.c
+++ b/tools/perf/util/symbol.c
@@ -1406,6 +1406,7 @@ int dso__load(struct dso *dso, struct map *map, symbol_filter_t filter)
struct symsrc ss_[2];
struct symsrc *syms_ss = NULL, *runtime_ss = NULL;
bool kmod;
+ unsigned char build_id[BUILD_ID_SIZE];
pthread_mutex_lock(&dso->lock);
@@ -1461,6 +1462,14 @@ int dso__load(struct dso *dso, struct map *map, symbol_filter_t filter)
dso->symtab_type == DSO_BINARY_TYPE__GUEST_KMODULE ||
dso->symtab_type == DSO_BINARY_TYPE__GUEST_KMODULE_COMP;
+
+ /*
+ * Read the build id if possible. This is required for
+ * DSO_BINARY_TYPE__BUILDID_DEBUGINFO to work
+ */
+ if (filename__read_build_id(dso->name, build_id, BUILD_ID_SIZE) > 0)
+ dso__set_build_id(dso, build_id);
+
/*
* Iterate over candidate debug images.
* Keep track of "interesting" ones (those which have a symtab, dynsym,
--
2.1.4
