Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.kernel > #1167482 > unrolled thread

[PATCH] perf report: Fix sort__sym_cmp to also compare end of symbol

Started byYannick Brosseau <scientist@fb.com>
First post2015-06-18 01:50 +0200
Last post2015-06-18 02:00 +0200
Articles 3 — 2 participants

Back to article view | Back to linux.kernel


Contents

  [PATCH] perf report: Fix sort__sym_cmp to also compare end of symbol Yannick Brosseau <scientist@fb.com> - 2015-06-18 01:50 +0200
    Re: [PATCH] perf report: Fix sort__sym_cmp to also compare end of  symbol Yannick Brosseau <scientist@fb.com> - 2015-06-18 02:00 +0200
    Re: [PATCH] perf report: Fix sort__sym_cmp to also compare end of  symbol Jeff Epler <jepler@unpythonic.net> - 2015-06-18 02:00 +0200

#1167482 — [PATCH] perf report: Fix sort__sym_cmp to also compare end of symbol

FromYannick Brosseau <scientist@fb.com>
Date2015-06-18 01:50 +0200
Subject[PATCH] perf report: Fix sort__sym_cmp to also compare end of symbol
Message-ID<pCvfJ-86E-45@gated-at.bofh.it>
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 <scientist@fb.com>
---
 tools/perf/util/sort.c | 8 +++-----
 1 file changed, 3 insertions(+), 5 deletions(-)

diff --git a/tools/perf/util/sort.c b/tools/perf/util/sort.c
index 4593f36..e226118 100644
--- a/tools/perf/util/sort.c
+++ b/tools/perf/util/sort.c
@@ -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
-- 
2.1.4

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [next] | [standalone]


#1167486 — Re: [PATCH] perf report: Fix sort__sym_cmp to also compare end of symbol

FromYannick Brosseau <scientist@fb.com>
Date2015-06-18 02:00 +0200
SubjectRe: [PATCH] perf report: Fix sort__sym_cmp to also compare end of symbol
Message-ID<pCvpn-8ib-1@gated-at.bofh.it>
In reply to#1167482
On 06/17/2015 04:53 PM, Jeff Epler wrote:
> On Wed, Jun 17, 2015 at 04:41:10PM -0700, Yannick Brosseau wrote:
>> 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.


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [next] | [standalone]


#1167495 — Re: [PATCH] perf report: Fix sort__sym_cmp to also compare end of symbol

FromJeff Epler <jepler@unpythonic.net>
Date2015-06-18 02:00 +0200
SubjectRe: [PATCH] perf report: Fix sort__sym_cmp to also compare end of symbol
Message-ID<pCvpn-8ib-3@gated-at.bofh.it>
In reply to#1167482
On Wed, Jun 17, 2015 at 04:41:10PM -0700, Yannick Brosseau wrote:
> 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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

[toc] | [prev] | [standalone]


Back to top | Article view | linux.kernel


csiph-web