Skip to contentSkip to conversation

perf report: Fix sort__sym_cmp to also compare end of symbol

PATCH In review Yannick Brosseau 4 participants 5 messages Jun 17, 2015 – Jun 19, 2015 perf events

lore
Share & tools
lore

Yannick Brosseau

author
#0 lore raw

PATCH 1/1 perf report: Fix sort__sym_cmp to also compare end of symbol

When using a map file from a JIT, due to memory reuse, we can obtain multiple symbols with the same start address but a different length.
The symbols__find does check for the end so not doing it in sort__sym_cmp was causing the hist_entry in the annotate part of a report to match to the wrong entry, causing a fatal error.

Signed-off-by Yannick Brosseau <[email protected]>
---
 tools/perf/util/sort.c | 8 +++-----
 1 file changed, 3 insertions(+), 5 deletions(-)
tools/perf/util/sort.c +3 -5
index 4593f36..e226118 100644
@@ -182,18 +182,16 @@ static int64_t _sort__addr_cmp(u64 left_ip, u64 right_ip)
 
 static int64_t _sort__sym_cmp(struct symbol *sym_l, struct symbol *sym_r)
 {
-	u64 ip_l, ip_r;
-
 	if (!sym_l || !sym_r)
 		return cmp_null(sym_l, sym_r);
 
 	if (sym_l == sym_r)
 		return 0;
 
-	ip_l = sym_l->start;
-	ip_r = sym_r->start;
+	if (sym_l->start != sym_r->start)
+		return (int64_t)(sym_r->start - sym_l->start);
 
-	return (int64_t)(ip_r - ip_l);
+	return (int64_t)(sym_r->end - sym_l->end);
 }
 
 static int64_t
Signature · 1 line
2.1.4
#1 lore raw
Quoted 3 lines · Yannick Brosseau

When using a map file from a JIT, due to memory reuse, we can obtain multiple symbols with the same start address but a different length.

Is there some reason it's impossible for the reused memory to have the same length / end address?

Jeff

author
#2 lore raw
Quoted 7 lines · Jeff Epler
Quoted 3 lines · Yannick Brosseau

When using a map file from a JIT, due to memory reuse, we can obtain multiple symbols with the same start address but a different length.

Is there some reason it's impossible for the reused memory to have the same length / end address?

It's possible that they are the same, and in that case the function returns 0.
The patch is adding the handling of the case where they are different.

maintainer
#3 lore raw

Em Wed, Jun 17, 2015 at 04:55:58PM -0700, Yannick Brosseau escreveu:

Quoted 11 lines · Jeff Epler
Quoted 7 lines · Yannick Brosseau
Quoted 3 lines

When using a map file from a JIT, due to memory reuse, we can obtain multiple symbols with the same start address but a different length.

Is there some reason it's impossible for the reused memory to have the same length / end address?

It's possible that they are the same, and in that case the function returns 0.
The patch is adding the handling of the case where they are different.

Looks sensible, applied.

- Arnaldo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in Please read the FAQ at http://www.tux.org/lkml/

merge bot
#4 lore raw
In reply to Yannick Brosseau
perf report: Fix sort__sym_cmp to also compare end of symbol
Commit-ID:  c05676c06232e6459a6106ddf0d4e154ce6cd859
Gitweb:     http://git.kernel.org/tip/c05676c06232e6459a6106ddf0d4e154ce6cd859
Author:     Yannick Brosseau <[email protected]>
AuthorDate: Wed, 17 Jun 2015 16:41:10 -0700
Committer:  Arnaldo Carvalho de Melo <[email protected]>
CommitDate: Fri, 19 Jun 2015 18:14:05 -0300

perf report: Fix sort__sym_cmp to also compare end of symbol

When using a map file from a JIT, due to memory reuse, we can obtain multiple symbols with the same start address but a different length.

The symbols__find does check for the end so not doing it in sort__sym_cmp was causing the hist_entry in the annotate part of a report to match to the wrong entry, causing a fatal error.

Signed-off-by Yannick Brosseau <[email protected]>
Cc Andi Kleen <[email protected]>
Cc Jiri Olsa <[email protected]>
Cc Paul Mackerras <[email protected]>
Cc Peter Zijlstra <[email protected]>
Cc [email protected]
Link http://lkml.kernel.org/r/[email protected] open here
Signed-off-by Arnaldo Carvalho de Melo <[email protected]>
---
 tools/perf/util/sort.c | 8 +++-----
 1 file changed, 3 insertions(+), 5 deletions(-)
tools/perf/util/sort.c +3 -5
index 09d4696..4c65a14 100644
@@ -182,18 +182,16 @@ static int64_t _sort__addr_cmp(u64 left_ip, u64 right_ip)
 
 static int64_t _sort__sym_cmp(struct symbol *sym_l, struct symbol *sym_r)
 {
-	u64 ip_l, ip_r;
-
 	if (!sym_l || !sym_r)
 		return cmp_null(sym_l, sym_r);
 
 	if (sym_l == sym_r)
 		return 0;
 
-	ip_l = sym_l->start;
-	ip_r = sym_r->start;
+	if (sym_l->start != sym_r->start)
+		return (int64_t)(sym_r->start - sym_l->start);
 
-	return (int64_t)(ip_r - ip_l);
+	return (int64_t)(sym_r->end - sym_l->end);
 }
 
 static int64_t

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in Please read the FAQ at http://www.tux.org/lkml/