From: Ian Munsie <imunsie@au1.ibm.com>
In the event that a DSO has not been identified, just print out
<unknown> instead of the instruction pointer as we previously were
doing, which is pretty meaningless for a shared object (at least to the
users perspective).
The IP we print out is fairly meaningless in general anyway - it's just
one (the first) of the many addresses that were lumped together as
unidentified, and could span many shared objects and symbols. In reality
if we see this <unknown> output the debugging output (report -D) is
going to be more useful anyway as we can see all the different address
that it represents.
If we are printing the symbols we are still going to see this IP in that
column anyway since they shouldn't resolve either.
Signed-off-by: Ian Munsie <imunsie@au1.ibm.com>
---
tools/perf/util/sort.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/tools/perf/util/sort.c b/tools/perf/util/sort.c
index b62a553..68dad55 100644
--- a/tools/perf/util/sort.c
+++ b/tools/perf/util/sort.c
@@ -170,7 +170,7 @@ static int hist_entry__dso_snprintf(struct hist_entry *self, char *bf,
return repsep_snprintf(bf, size, "%-*s", width, dso_name);
}
- return repsep_snprintf(bf, size, "%*Lx", width, self->ip);
+ return repsep_snprintf(bf, size, "%-*s", width, "<unknown>");
}
/* --sort symbol */
--
1.7.2.3
--
