aboutsummaryrefslogtreecommitdiffstats
path: root/tools/perf
diff options
context:
space:
mode:
authorArnaldo Carvalho de Melo <acme@redhat.com>2018-03-01 09:33:59 -0500
committerArnaldo Carvalho de Melo <acme@redhat.com>2018-03-05 09:50:15 -0500
commit9cf195f80c5e8a6d779119a7d292e537315d2ea6 (patch)
treea1f9bad3bcb024c612872bbcb53403f907dc9b5a /tools/perf
parent626af862da9c650e80bdea44684be9334f8eb75b (diff)
perf annotate browser: Be more robust when drawing jump arrows
This first happened with a gcc function, _cpp_lex_token, that has the usual jumps: │1159e6c: ↓ jne 115aa32 <_cpp_lex_token@@Base+0xf92> I.e. jumps to a label inside that function (_cpp_lex_token), and those works, but also this kind: │1159e8b: ↓ jne c469be <cpp_named_operator2name@@Base+0xa72> I.e. jumps to another function, outside _cpp_lex_token, which are not being correctly handled generating as a side effect references to ab->offset[] entries that are set to NULL, so to make this code more robust, check that here. A proper fix for will be put in place, looking at the function name right after the '<' token and probably treating this like a 'call' instruction. For now just don't draw the arrow. Reported-by: Ingo Molnar <mingo@kernel.org> Tested-by: Ingo Molnar <mingo@kernel.org> Reported-by: Linus Torvalds <torvalds@linux-foundation.org> Cc: Adrian Hunter <adrian.hunter@intel.com> Cc: David Ahern <dsahern@gmail.com> Cc: Jiri Olsa <jolsa@kernel.org> Cc: Namhyung Kim <namhyung@kernel.org> Cc: Wang Nan <wangnan0@huawei.com> Cc: Jin Yao <yao.jin@intel.com> Cc: Kan Liang <kan.liang@intel.com> Link: https://lkml.kernel.org/n/tip-5tzvb875ep2sel03aeefgmud@git.kernel.org Signed-off-by: Arnaldo Carvalho de Melo <acme@redhat.com>
Diffstat (limited to 'tools/perf')
-rw-r--r--tools/perf/ui/browsers/annotate.c25
1 files changed, 25 insertions, 0 deletions
diff --git a/tools/perf/ui/browsers/annotate.c b/tools/perf/ui/browsers/annotate.c
index 286427975112..fbf927cf775d 100644
--- a/tools/perf/ui/browsers/annotate.c
+++ b/tools/perf/ui/browsers/annotate.c
@@ -327,7 +327,32 @@ static void annotate_browser__draw_current_jump(struct ui_browser *browser)
327 if (!disasm_line__is_valid_jump(cursor, sym)) 327 if (!disasm_line__is_valid_jump(cursor, sym))
328 return; 328 return;
329 329
330 /*
331 * This first was seen with a gcc function, _cpp_lex_token, that
332 * has the usual jumps:
333 *
334 * │1159e6c: ↓ jne 115aa32 <_cpp_lex_token@@Base+0xf92>
335 *
336 * I.e. jumps to a label inside that function (_cpp_lex_token), and
337 * those works, but also this kind:
338 *
339 * │1159e8b: ↓ jne c469be <cpp_named_operator2name@@Base+0xa72>
340 *
341 * I.e. jumps to another function, outside _cpp_lex_token, which
342 * are not being correctly handled generating as a side effect references
343 * to ab->offset[] entries that are set to NULL, so to make this code
344 * more robust, check that here.
345 *
346 * A proper fix for will be put in place, looking at the function
347 * name right after the '<' token and probably treating this like a
348 * 'call' instruction.
349 */
330 target = ab->offsets[cursor->ops.target.offset]; 350 target = ab->offsets[cursor->ops.target.offset];
351 if (target == NULL) {
352 ui_helpline__printf("WARN: jump target inconsistency, press 'o', ab->offsets[%#x] = NULL\n",
353 cursor->ops.target.offset);
354 return;
355 }
331 356
332 bcursor = browser_line(&cursor->al); 357 bcursor = browser_line(&cursor->al);
333 btarget = browser_line(target); 358 btarget = browser_line(target);