Implement lbr-as-callgraph v10

From: Andi Kleen <[email protected]>

Move the code to resolve and add a new callchain entry into a new add_callchain_ip function. This will be used in the next patches to add LBRs too.

No change in behavior.

tools/perf/util/machine.c +95 -8

+	for (i = 0; i < nr; i++) {
+		int h = hash_64(l[i].from, CHASHBITS) % CHASHSZ;
+
+		/* no collision handling for now */
+		if (chash[h] == NO_ENTRY) {
+			chash[h] = i;
+		} else if (l[chash[h]].from == l[i].from) {
+			bool is_loop = true;
+			/* check if it is a real loop */
+			off = 0;
+			for (j = chash[h]; j < i && i + off < nr; j++, off++)
+				if (l[j].from != l[i + off].from) {
+					is_loop = false;
+					break;
+				}
+			if (is_loop) {
+				memmove(l + i, l + i + off,
+					(nr - (i + off)) * sizeof(*l));
+				nr -= off;
+			}
+		}
+	}
+	return nr;
+}
+
 static int thread__resolve_callchain_sample(struct thread *thread,
 					     struct ip_callchain *chain,
+					     struct branch_stack *branch,
 					     struct symbol **parent,
 					     struct addr_location *root_al,
 					     int max_stack)

@@ -1438,22 +1484,82 @@ static int thread__resolve_callchain_sample(struct thread *thread,
 	int i;
 	int j;
 	int err;
-	int skip_idx __maybe_unused;
+	int skip_idx = -1;
+	int first_call = 0;
+
+	/*
+	 * Based on DWARF debug information, some architectures skip
+	 * a callchain entry saved by the kernel.
+	 */
+	if (chain->nr < PERF_MAX_STACK_DEPTH)
+		skip_idx = arch_skip_callchain_idx(thread, chain);
 
 	callchain_cursor_reset(&callchain_cursor);
 
+	/*
+	 * Add branches to call stack for easier browsing. This gives
+	 * more context for a sample than just the callers.
+	 *
+	 * This uses individual histograms of paths compared to the
+	 * aggregated histograms the normal LBR mode uses.
+	 *
+	 * Limitations for now:
+	 * - No extra filters
+	 * - No annotations (should annotate somehow)
+	 */
+
+	if (branch && callchain_param.branch_callstack) {
+		int nr = min(max_stack, (int)branch->nr);
+		struct branch_entry be[nr];
+
+		if (branch->nr > PERF_MAX_BRANCH_DEPTH) {
+			pr_warning("corrupted branch chain. skipping...\n");
+			goto check_calls;
+		}
+
+		for (i = 0; i < nr; i++) {
+			if (callchain_param.order == ORDER_CALLEE) {
+				be[i] = branch->entries[i];
+				/*
+				 * Check for overlap into the callchain.
+				 * The return address is one off compared to
+				 * the branch entry. To adjust for this
+				 * assume the calling instruction is not longer
+				 * than 8 bytes.
+				 */
+				if (i == skip_idx ||
+				    chain->ips[first_call] >= PERF_CONTEXT_MAX)
+					first_call++;
+				else if (be[i].from < chain->ips[first_call] &&
+				    be[i].from >= chain->ips[first_call] - 8)
+					first_call++;
+			} else
+				be[i] = branch->entries[branch->nr - i - 1];
+		}
+
+		nr = remove_loops(be, nr);
+
+		for (i = 0; i < nr; i++) {
+			err = add_callchain_ip(thread, parent, root_al,
+					       -1, be[i].to);
+			if (!err)
+				err = add_callchain_ip(thread, parent, root_al,
+						       -1, be[i].from);
+			if (err == -EINVAL)
+				break;
+			if (err)
+				return err;
+		}
+		chain_nr -= nr;
+	}
+
+check_calls:
 	if (chain->nr > PERF_MAX_STACK_DEPTH) {
 		pr_warning("corrupted callchain. skipping...\n");
 		return 0;
 	}
 
-	/*
-	 * Based on DWARF debug information, some architectures skip
-	 * a callchain entry saved by the kernel.
-	 */
-	skip_idx = arch_skip_callchain_idx(thread, chain);
-
-	for (i = 0; i < chain_nr; i++) {
+	for (i = first_call; i < chain_nr; i++) {
 		u64 ip;
 
 		if (callchain_param.order == ORDER_CALLEE)

@@ -1517,6 +1623,7 @@ int thread__resolve_callchain(struct thread *thread,
 			      int max_stack)
 {
 	int ret = thread__resolve_callchain_sample(thread, sample->callchain,
+						   sample->branch_stack,
 						   parent, root_al, max_stack);
 	if (ret)
 		return ret;

tools/perf/util/symbol.h +2 -1

index ded3ca7..b364d96 100644
@@ -123,7 +123,8 @@ struct symbol_conf {
 			demangle,
 			demangle_kernel,
 			filter_relative,
-			show_hist_headers;
+			show_hist_headers,
+			branch_callstack;
 	const char	*vmlinux_name,
 			*kallsyms_name,
 			*source_prefix,

Signature · 1 line

1.9.3

Em Wed, Nov 12, 2014 at 06:05:20PM -0800, Andi Kleen escreveu:

tools/perf/util/machine.c struct branch_info *sample__resolve_bstack(struct perf_sample *sample, · line 1449

Quoted 8 lines

tools/perf/util/machine.c +8 -0

+static int remove_loops(struct branch_entry *l, int nr)
+{
+	int i, j, off;
+	unsigned char chash[CHASHSZ];
+
+	memset(chash, NO_ENTRY, sizeof(chash));
+
+	BUG_ON(nr >= 256);

What is wrong with return -1 and propagating the error, so that the user is informed if the data being processed is bogus, stop processing with a warning or continue processing if finding the next valid record is possible?

Quoted 14 lines

Em Wed, Nov 12, 2014 at 06:05:20PM -0800, Andi Kleen escreveu:

tools/perf/util/machine.c struct branch_info *sample__resolve_bstack(struct perf_sample *sample, · line 1449

Quoted 8 lines

tools/perf/util/machine.c +8 -0

+static int remove_loops(struct branch_entry *l, int nr)
+{
+	int i, j, off;
+	unsigned char chash[CHASHSZ];
+
+	memset(chash, NO_ENTRY, sizeof(chash));
+
+	BUG_ON(nr >= 256);

What is wrong with return -1 and propagating the error, so that the user is informed if the data being processed is bogus, stop processing with a warning or continue processing if finding the next valid record is possible?

The error doesn't depend on the record. There is a check for the record being < 127 in front of this. This is merely to catch that if someone increases PERF_MAX_BRANCH_DEPTH to below 255 they need to increase the type of the hash table from u8.

Em Thu, Nov 13, 2014 at 08:52:08PM +0100, Andi Kleen escreveu:

Quoted 16 lines · Arnaldo Carvalho de Melo

Quoted 14 lines

Em Wed, Nov 12, 2014 at 06:05:20PM -0800, Andi Kleen escreveu:

tools/perf/util/machine.c struct branch_info *sample__resolve_bstack(struct perf_sample *sample, · line 1449

Quoted 8 lines

tools/perf/util/machine.c +8 -0

+static int remove_loops(struct branch_entry *l, int nr)
+{
+	int i, j, off;
+	unsigned char chash[CHASHSZ];
+
+	memset(chash, NO_ENTRY, sizeof(chash));
+
+	BUG_ON(nr >= 256);

What is wrong with return -1 and propagating the error, so that the user is informed if the data being processed is bogus, stop processing with a warning or continue processing if finding the next valid record is possible?

Quoted 4 lines

The error doesn't depend on the record. There is a check for the record being < 127 in front of this. This is merely to catch that if someone increases PERF_MAX_BRANCH_DEPTH to below 255 they need to increase the type of the hash table from u8.

Ok, so this would be better as a BUILD_BUG_ON?

Like:

#define CHASHSZ 127
#define CHASHBITS 7
#define NO_ENTRY 0xff

#define PERF_MAX_BRANCH_DEPTH 127

/* Remove loops. */
static int remove_loops(struct branch_entry *l, int nr)

{
	int i, j, off;
	unsigned char chash[CHASHSZ];

	memset(chash, NO_ENTRY, sizeof(chash));

	/* Change the type of the chash table, u8 is not enough now */
	BUILD_BUG_ON(PERF_MAX_BRANCH_DEPTH >= 256);
	for (i = 0; i < nr; i++) {
		int h = hash_64(l[i].from, CHASHBITS) % CHASHSZ;

-------------------------------------

- Arnaldo

Quoted 17 lines

Em Thu, Nov 13, 2014 at 08:52:08PM +0100, Andi Kleen escreveu:

Quoted 16 lines · Arnaldo Carvalho de Melo

Quoted 14 lines

Em Wed, Nov 12, 2014 at 06:05:20PM -0800, Andi Kleen escreveu:

tools/perf/util/machine.c struct branch_info *sample__resolve_bstack(struct perf_sample *sample, · line 1449

Quoted 8 lines

tools/perf/util/machine.c +8 -0

+static int remove_loops(struct branch_entry *l, int nr)
+{
+	int i, j, off;
+	unsigned char chash[CHASHSZ];
+
+	memset(chash, NO_ENTRY, sizeof(chash));
+
+	BUG_ON(nr >= 256);

What is wrong with return -1 and propagating the error, so that the user is informed if the data being processed is bogus, stop processing with a warning or continue processing if finding the next valid record is possible?

Quoted 6 lines

Quoted 4 lines

The error doesn't depend on the record. There is a check for the record being < 127 in front of this. This is merely to catch that if someone increases PERF_MAX_BRANCH_DEPTH to below 255 they need to increase the type of the hash table from u8.

Ok, so this would be better as a BUILD_BUG_ON?

Yes that should work.

-Andi

Quoted 26 lines

Like:

#define CHASHSZ 127
#define CHASHBITS 7
#define NO_ENTRY 0xff

#define PERF_MAX_BRANCH_DEPTH 127

/* Remove loops. */
static int remove_loops(struct branch_entry *l, int nr)

{
	int i, j, off;
	unsigned char chash[CHASHSZ];

	memset(chash, NO_ENTRY, sizeof(chash));

	/* Change the type of the chash table, u8 is not enough now */
	BUILD_BUG_ON(PERF_MAX_BRANCH_DEPTH >= 256);
	for (i = 0; i < nr; i++) {
		int h = hash_64(l[i].from, CHASHBITS) % CHASHSZ;

-------------------------------------

- Arnaldo

Signature · 1 line

[email protected] -- Speaking for myself only.

From: Andi Kleen <[email protected]>

Use the relative address, this makes get_srcline work correctly in the end.

Signed-off-by Andi Kleen <[email protected]>

---
 tools/perf/util/machine.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

tools/perf/util/machine.c +1 -1

index 2e16d69..066e963 100644
@@ -1411,7 +1411,7 @@ static int add_callchain_ip(struct thread *thread,
 		}
 	}
 
-	return callchain_cursor_append(&callchain_cursor, ip, al.map, al.sym);
+	return callchain_cursor_append(&callchain_cursor, al.addr, al.map, al.sym);
 }
 
 struct branch_info *sample__resolve_bstack(struct perf_sample *sample,

Signature · 1 line

1.9.3

Em Wed, Nov 12, 2014 at 06:05:21PM -0800, Andi Kleen escreveu:

Quoted 4 lines

From: Andi Kleen <[email protected]>

Use the relative address, this makes get_srcline work correctly in the end.

Applied.

Quoted 13 lines

Signed-off-by Andi Kleen <[email protected]>

---
 tools/perf/util/machine.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

tools/perf/util/machine.c +0 -0

index 2e16d69..066e963 100644
@@ -1411,7 +1411,7 @@ static int add_callchain_ip(struct thread *thread,
 		}
 	}
 

Quoted 7 lines

tools/perf/util/machine.c +1 -1

-	return callchain_cursor_append(&callchain_cursor, ip, al.map, al.sym);
+	return callchain_cursor_append(&callchain_cursor, al.addr, al.map, al.sym);
 }
 
 struct branch_info *sample__resolve_bstack(struct perf_sample *sample,

Signature · 1 line

1.9.3

this patch also changed the output of callchain entries with 'map' but with no symbol, like in following diff:

---

                  ---get_next_seq
                     |

(quoted diff) +3 -4

-                    |--70.16%-- 0x40e1cf
+                    |--70.16%-- 0xe1cf
                     |          0x841f0f
                     |
-                    |--25.83%-- 0x40e153
+                    |--25.83%-- 0xe153
                     |          0x841f0f
                     |
-                     --4.00%-- 0x40e27f
+                     --4.00%-- 0xe27f
--

I'm guessing this change was unintentional..? in case we have a map but no symbol seeing full address is more clear than relative at least for binary, not sure about DSOs..

thoughts?

thanks,
jirka

---

tools/perf/util/callchain.c +14 -6

index 64b377e591e4..a4fb25fb26f5 100644
@@ -816,22 +816,30 @@ out:
 char *callchain_list__sym_name(struct callchain_list *cl,
 			       char *bf, size_t bfsize, bool show_dso)
 {
+	struct map *map = cl->ms.map;
 	int printed;
 
 	if (cl->ms.sym) {
 		if (callchain_param.key == CCKEY_ADDRESS &&
-		    cl->ms.map && !cl->srcline)
-			cl->srcline = get_srcline(cl->ms.map->dso,
-						  map__rip_2objdump(cl->ms.map,
-								    cl->ip),
+		    map && !cl->srcline) {
+			cl->srcline = get_srcline(map->dso,
+						  map__rip_2objdump(map, cl->ip),
 						  cl->ms.sym, false);
+		}
 		if (cl->srcline)
 			printed = scnprintf(bf, bfsize, "%s %s",
 					cl->ms.sym->name, cl->srcline);
 		else
 			printed = scnprintf(bf, bfsize, "%s", cl->ms.sym->name);
-	} else
-		printed = scnprintf(bf, bfsize, "%#" PRIx64, cl->ip);
+	} else {
+		/*
+		 * The cl->ip value is unbased ip (applied map->map_ip).
+		 * Display the unmap ip in case we have no symbol.
+		 */
+		u64 addr = map ? map->unmap_ip(map, cl->ip) : cl->ip;
+
+		printed = scnprintf(bf, bfsize, "%#" PRIx64, addr);
+	}
 
 	if (show_dso)
 		scnprintf(bf + printed, bfsize - printed, " %s",

From: Andi Kleen <[email protected]>

Refactor the duplicated code to resolve the symbol name or the address of a symbol into a single function.

Used in next patch to add common functionality.

From: Andi Kleen <[email protected]>

For lbr-as-callgraph we need to see the line number in the history, because many LBR entries can be in a single function, and just showing the same function name many times is not useful.

When the history code is configured to sort by address, also try to resolve the address to a file:srcline and display this in the browser. If that doesn't work still display the address.

This can be also useful without LBRs for understanding which call in a large function (or in which inlined function) called something else.

Contains fixes from Namhyung Kim

From: Andi Kleen <[email protected]>

For perf report with --sort srcline only print the base source file name. This makes the results generally fit much better to the screen. The path is usually not that useful anyways because it is often from different systems.

Signed-off-by Andi Kleen <[email protected]>

---
 tools/perf/util/srcline.c | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

tools/perf/util/srcline.c +1 -1

index c6a7cdc..ac877f9 100644
@@ -274,7 +274,7 @@ char *get_srcline(struct dso *dso, unsigned long addr)
 	if (!addr2line(dso_name, addr, &file, &line, dso))
 		goto out;
 
-	if (asprintf(&srcline, "%s:%u", file, line) < 0) {
+	if (asprintf(&srcline, "%s:%u", basename(file), line) < 0) {
 		free(file);
 		goto out;
 	}

Signature · 1 line

1.9.3

From: Andi Kleen <[email protected]>

With srcline key/sort'ing it's useful to have line numbers in the annotate window. This patch implements this.

Use objdump -l to request the line numbers and
save them in the line structure. Then the browser
displays them for source lines.

The line numbers are not displayed by default, but can be toggled on with 'k'

There is one unfortunate problem with this setup. For lines not containing source and which are outside functions objdump -l reports line numbers off by a few: it always reports the first line number in the next function even for lines that are outside the function.
I haven't found a nice way to detect/correct this. Probably objdump has to be fixed.
See https://sourceware.org/bugzilla/show_bug.cgi?id=16433

The line numbers are still useful even with these problems, as most are correct and the ones which are not are nearby.

v2: Fix help text. Handle (discriminator...) output in objdump. Left align the line numbers.

Signed-off-by Andi Kleen <[email protected]>

---
 tools/perf/ui/browsers/annotate.c | 13 ++++++++++++-
 tools/perf/util/annotate.c        | 30 +++++++++++++++++++++++++-----
 tools/perf/util/annotate.h        |  1 +
 3 files changed, 38 insertions(+), 6 deletions(-)

tools/perf/ui/browsers/annotate.c +12 -1

index f0697a3..1e0a2fd 100644
@@ -27,6 +27,7 @@ static struct annotate_browser_opt {
 	bool hide_src_code,
 	     use_offset,
 	     jump_arrows,
+	     show_linenr,
 	     show_nr_jumps;
 } annotate_browser__opts = {
 	.use_offset	= true,

@@ -128,7 +129,11 @@ static void annotate_browser__write(struct ui_browser *browser, void *entry, int
 	if (!*dl->line)
 		slsmg_write_nstring(" ", width - pcnt_width);
 	else if (dl->offset == -1) {
-		printed = scnprintf(bf, sizeof(bf), "%*s  ",
+		if (dl->line_nr && annotate_browser__opts.show_linenr)
+			printed = scnprintf(bf, sizeof(bf), "%-*d ",
+					ab->addr_width + 1, dl->line_nr);
+		else
+			printed = scnprintf(bf, sizeof(bf), "%*s  ",
 				    ab->addr_width, " ");
 		slsmg_write_nstring(bf, printed);
 		slsmg_write_nstring(dl->line, width - printed - pcnt_width + 1);

@@ -733,6 +738,7 @@ static int annotate_browser__run(struct annotate_browser *browser,
 		"o             Toggle disassembler output/simplified view\n"
 		"s             Toggle source code view\n"
 		"/             Search string\n"
+		"k             Toggle line numbers\n"
 		"r             Run available scripts\n"
 		"?             Search string backwards\n");
 			continue;

@@ -741,6 +747,10 @@ static int annotate_browser__run(struct annotate_browser *browser,
 				script_browse(NULL);
 				continue;
 			}
+		case 'k':
+			annotate_browser__opts.show_linenr =
+				!annotate_browser__opts.show_linenr;
+			break;
 		case 'H':
 			nd = browser->curr_hot;
 			break;

@@ -984,6 +994,7 @@ static struct annotate_config {
 } annotate__configs[] = {
 	ANNOTATE_CFG(hide_src_code),
 	ANNOTATE_CFG(jump_arrows),
+	ANNOTATE_CFG(show_linenr),
 	ANNOTATE_CFG(show_nr_jumps),
 	ANNOTATE_CFG(use_offset),
 };

tools/perf/util/annotate.c +25 -5

index 7dabde1..d821223 100644
@@ -17,11 +17,13 @@
 #include "debug.h"
 #include "annotate.h"
 #include "evsel.h"
+#include <regex.h>
 #include <pthread.h>
 #include <linux/bitops.h>
 
 const char 	*disassembler_style;
 const char	*objdump_path;
+static regex_t	 file_lineno;
 
 static struct ins *ins__find(const char *name);
 static int disasm_line__parse(char *line, char **namep, char **rawp);

@@ -570,13 +572,15 @@ out_free_name:
 	return -1;
 }
 
-static struct disasm_line *disasm_line__new(s64 offset, char *line, size_t privsize)
+static struct disasm_line *disasm_line__new(s64 offset, char *line,
+					size_t privsize, int line_nr)
 {
 	struct disasm_line *dl = zalloc(sizeof(*dl) + privsize);
 
 	if (dl != NULL) {
 		dl->offset = offset;
 		dl->line = strdup(line);
+		dl->line_nr = line_nr;
 		if (dl->line == NULL)
 			goto out_delete;
 

@@ -788,13 +792,15 @@ static int disasm_line__print(struct disasm_line *dl, struct symbol *sym, u64 st
  * The ops.raw part will be parsed further according to type of the instruction.
  */
 static int symbol__parse_objdump_line(struct symbol *sym, struct map *map,
-				      FILE *file, size_t privsize)
+				      FILE *file, size_t privsize,
+				      int *line_nr)
 {
 	struct annotation *notes = symbol__annotation(sym);
 	struct disasm_line *dl;
 	char *line = NULL, *parsed_line, *tmp, *tmp2, *c;
 	size_t line_len;
 	s64 line_ip, offset = -1;
+	regmatch_t match[2];
 
 	if (getline(&line, &line_len, file) < 0)
 		return -1;

@@ -812,6 +818,12 @@ static int symbol__parse_objdump_line(struct symbol *sym, struct map *map,
 	line_ip = -1;
 	parsed_line = line;
 
+	/* /filename:linenr ? Save line number and ignore. */
+	if (regexec(&file_lineno, line, 2, match, 0) == 0) {
+		*line_nr = atoi(line + match[1].rm_so);
+		return 0;
+	}
+
 	/*
 	 * Strip leading spaces:
 	 */

@@ -842,8 +854,9 @@ static int symbol__parse_objdump_line(struct symbol *sym, struct map *map,
 			parsed_line = tmp2 + 1;
 	}
 
-	dl = disasm_line__new(offset, parsed_line, privsize);
+	dl = disasm_line__new(offset, parsed_line, privsize, *line_nr);
 	free(line);
+	(*line_nr)++;
 
 	if (dl == NULL)
 		return -1;

@@ -869,6 +882,11 @@ static int symbol__parse_objdump_line(struct symbol *sym, struct map *map,
 	return 0;
 }
 
+static __attribute__((constructor)) void symbol__init_regexpr(void)
+{
+	regcomp(&file_lineno, "^/[^:]+:([0-9]+)", REG_EXTENDED);
+}
+
 static void delete_last_nop(struct symbol *sym)
 {
 	struct annotation *notes = symbol__annotation(sym);

@@ -904,6 +922,7 @@ int symbol__annotate(struct symbol *sym, struct map *map, size_t privsize)
 	char symfs_filename[PATH_MAX];
 	struct kcore_extract kce;
 	bool delete_extract = false;
+	int lineno = 0;
 
 	if (filename)
 		symbol__join_symfs(symfs_filename, filename);

@@ -982,7 +1001,7 @@ fallback:
 	snprintf(command, sizeof(command),
 		 "%s %s%s --start-address=0x%016" PRIx64
 		 " --stop-address=0x%016" PRIx64
-		 " -d %s %s -C %s 2>/dev/null|grep -v %s|expand",
+		 " -l -d %s %s -C %s 2>/dev/null|grep -v %s|expand",
 		 objdump_path ? objdump_path : "objdump",
 		 disassembler_style ? "-M " : "",
 		 disassembler_style ? disassembler_style : "",

@@ -999,7 +1018,8 @@ fallback:
 		goto out_free_filename;
 
 	while (!feof(file))
-		if (symbol__parse_objdump_line(sym, map, file, privsize) < 0)
+		if (symbol__parse_objdump_line(sym, map, file, privsize,
+			    &lineno) < 0)
 			break;
 
 	/*

tools/perf/util/annotate.h +1 -0

index 112d6e2..0784a94 100644
@@ -58,6 +58,7 @@ struct disasm_line {
 	char		    *line;
 	char		    *name;
 	struct ins	    *ins;
+	int		    line_nr;
 	struct ins_operands ops;
 };
 

Signature · 1 line

1.9.3

From: Andi Kleen <[email protected]>

asprintf corrupts memory on some older glibc versions. Provide a replacement. This fixes various segfaults with --branch-history on older Fedoras.

v2: Remove bogus hunk.
Support arbitrary size (Geert Uytterhoeven)

Signed-off-by Andi Kleen <[email protected]>

---
 tools/perf/Makefile.perf    |  1 +
 tools/perf/builtin-report.c |  1 +
 tools/perf/util/asprintf.c  | 34 ++++++++++++++++++++++++++++++++++
 3 files changed, 36 insertions(+)
 create mode 100644 tools/perf/util/asprintf.c

tools/perf/Makefile.perf +1 -0

index aecf61dc..9db4ff1 100644
@@ -395,6 +395,7 @@ LIB_OBJS += $(OUTPUT)util/vdso.o
 LIB_OBJS += $(OUTPUT)util/stat.o
 LIB_OBJS += $(OUTPUT)util/record.o
 LIB_OBJS += $(OUTPUT)util/srcline.o
+LIB_OBJS += $(OUTPUT)util/asprintf.o
 LIB_OBJS += $(OUTPUT)util/data.o
 LIB_OBJS += $(OUTPUT)util/tsc.o
 LIB_OBJS += $(OUTPUT)util/cloexec.o

tools/perf/builtin-report.c +0 -0

index fb272ff..493f011 100644

tools/perf/builtin-report.c +0 -0

 		symbol_conf.use_callchain = true;
 		callchain_register_param(&callchain_param);
 		if (sort_order == NULL)

tools/perf/util/asprintf.c new file +34 -0

new file mode 100644
index 0000000..6177ee8
@@ -0,0 +1,34 @@
+/* Replacement for asprintf as it's buggy in older glibc versions */
+#include <stdio.h>
+#include <stdarg.h>
+#include <stdlib.h>
+#include <string.h>
+
+int vasprintf(char **str, const char *fmt, va_list ap)
+{
+	va_list ao;
+	char buf[1024];
+	int len;
+
+	va_copy(ao, ap);
+	len = vsnprintf(buf, sizeof(buf), fmt, ap);
+	*str = malloc(len + 1);
+	if (!*str)
+		return -1;
+	if ((size_t)len < sizeof(buf)) {
+		strcpy(*str, buf);
+		return len;
+	}
+	return vsnprintf(*str, len + 1, fmt, ao);
+}
+
+int asprintf(char **str, const char *fmt, ...)
+{
+	va_list ap;
+	int ret;
+
+	va_start(ap, fmt);
+	ret = vasprintf(str, fmt, ap);
+	va_end(ap);
+	return ret;
+}

Signature · 1 line

1.9.3

tools/perf/builtin-report.c repeat: · line 765

Quoted 9 lines

tools/perf/builtin-report.c +1 -0

index fb272ff..493f011 100644
@@ -762,6 +762,7 @@ repeat:
 	}
 	if (branch_call_mode) {
 		callchain_param.branch_callstack = 1;
+		callchain_param.key = CCKEY_ADDRESS;

unrelated hunk?

[Reworks to address all the review feedback. Rebased to latest tree] [Just a repost after a rebase]
[Even more review feedback and some bugs addressed.] [Only port to changes in perf/core. No other changes.] [Rebase to latest perf/core]
[Another rebase. No changes]

This patchkit implements lbr-as-callgraphs in per freport, as an alternative way to present LBR information.

Current perf report does a histogram over the branch edges, which is useful to look at basic blocks, but doesn't tell you anything about the larger control flow behaviour.

This patchkit adds a new option --branch-history that adds the branch paths to the callgraph history instead.

This allows to reason about individual branch paths leading to specific samples.

Also available at
git://git.kernel.org/pub/scm/linux/kernel/git/ak/linux-misc perf/lbr-callgraph8

v2:
- rebased on perf/core
- fix various issues
- rename the option to --branch-history
- various fixes to display the information more concise v3:
- White space changes
- Consolidate some patches
- Update some descriptions
v4:
- Fix various display problems
- Unknown srcline is now printed as symbol+offset
- Refactor some code to address review feedback
- Merge with latest tip
- Fix missing srcline display in stdio hist output. v5:
- Rename functions
- Fix gtk build problem
- Fix crash without -g
- Improve error messages
- Improve srcline display in various ways
v6:
- Port to latest perf/core
v7:
- Really port to latest perf/core
v8:
- Rebased on 3.16-rc1
v9:
- Rebase on 3.17-rc* tip/perf/core
v10:
- Rebase to latest tree.
- Address review feedback (except where commented). See the individual patches for changelog. I dropped the -v option support.

Example output:

% perf record -b -g ./tsrc/tcall
[ perf record: Woken up 1 times to write data ]
[ perf record: Captured and wrote 0.044 MB perf.data (~1923 samples) ] % perf report --branch-history
...
54.91% tcall.c:6 [.] f2 tcall
|
|--65.53%-- f2 tcall.c:5
| |
| |--70.83%-- f1 tcall.c:11
| | f1 tcall.c:10
| | main tcall.c:18
| | main tcall.c:18
| | main tcall.c:17
| | main tcall.c:17
| | f1 tcall.c:13
| | f1 tcall.c:13
| | f2 tcall.c:7
| | f2 tcall.c:5
| | f1 tcall.c:12
| | f1 tcall.c:12
| | f2 tcall.c:7
| | f2 tcall.c:5
| | f1 tcall.c:11

Em Wed, Nov 12, 2014 at 06:05:18PM -0800, Andi Kleen escreveu:

Quoted 9 lines

[Reworks to address all the review feedback. Rebased to latest tree] [Just a repost after a rebase]
[Even more review feedback and some bugs addressed.] [Only port to changes in perf/core. No other changes.] [Rebase to latest perf/core]
[Another rebase. No changes]

This patchkit implements lbr-as-callgraphs in per freport, as an alternative way to present LBR information.

Ok, I have this in my perf/core branch, but I need to test it further, as I couldn't get the output that appears on some of the changelogs.

If you could take a look at

git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux perf/core

To see if I made some mistake, that would be of help,

Em Wed, Nov 12, 2014 at 06:05:18PM -0800, Andi Kleen escreveu:

Quoted 9 lines

[Reworks to address all the review feedback. Rebased to latest tree] [Just a repost after a rebase]
[Even more review feedback and some bugs addressed.] [Only port to changes in perf/core. No other changes.] [Rebase to latest perf/core]
[Another rebase. No changes]

This patchkit implements lbr-as-callgraphs in per freport, as an alternative way to present LBR information.

Ok, I have this in my perf/core branch, but I need to test it further, as I couldn't get the output that appears on some of the changelogs.

If you could take a look at

git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux perf/core

To see if I made some mistake, that would be of help,

Quoted 14 lines · Arnaldo Carvalho de Melo

Em Wed, Nov 12, 2014 at 06:05:18PM -0800, Andi Kleen escreveu:

Quoted 9 lines

[Reworks to address all the review feedback. Rebased to latest tree] [Just a repost after a rebase]
[Even more review feedback and some bugs addressed.] [Only port to changes in perf/core. No other changes.] [Rebase to latest perf/core]
[Another rebase. No changes]

This patchkit implements lbr-as-callgraphs in per freport, as an alternative way to present LBR information.

Ok, I have this in my perf/core branch, but I need to test it further, as I couldn't get the output that appears on some of the changelogs.

Quoted 6 lines

If you could take a look at

git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux perf/core

To see if I made some mistake, that would be of help,

I'm getting compile error for DEBUG=1

jirka

[jolsa@krava perf]$ make DEBUG=1 JOBS=1
BUILD: Doing 'make -j1' parallel build
CC util/machine.o
In file included from /home/jolsa/kernel.org/linux-perf/tools/perf/util/include/../../../../include/uapi/linux/swab.h:5:0,

                 from /home/jolsa/kernel.org/linux-perf/tools/perf/util/include/asm/byteorder.h:2,
                 from /home/jolsa/kernel.org/linux-perf/include/uapi/linux/perf_event.h:19,
                 from util/../perf.h:7,
                 from util/callchain.h:4,
                 from util/machine.c:1:
util/machine.c: In function ‘remove_loops’:
/home/jolsa/kernel.org/linux-perf/tools/include/linux/compiler.h:64:20: error: call to ‘__compiletime_assert_1450’ declared with attribute error: Please upgrade the type of the hash table from unsigned char
    prefix ## suffix();    \
                    ^

/home/jolsa/kernel.org/linux-perf/tools/include/linux/compiler.h:69:2: note: in expansion of macro ‘__compiletime_assert’
__compiletime_assert(condition, msg, prefix, suffix)
^
/home/jolsa/kernel.org/linux-perf/tools/include/linux/compiler.h:81:2: note: in expansion of macro ‘_compiletime_assert’
_compiletime_assert(condition, msg, __compiletime_assert_, __LINE__)
^
/home/jolsa/kernel.org/linux-perf/tools/include/linux/bug.h:13:37: note: in expansion of macro ‘compiletime_assert’

 #define BUILD_BUG_ON_MSG(cond, msg) compiletime_assert(!(cond), msg)
                                     ^

util/machine.c:1449:2: note: in expansion of macro ‘BUILD_BUG_ON_MSG’
BUILD_BUG_ON_MSG(PERF_MAX_BRANCH_DEPTH > 127,
^
make[1]: *** [util/machine.o] Error 1
make: *** [all] Error 2

Quoted 17 lines · Jiri Olsa

Quoted 16 lines · Arnaldo Carvalho de Melo

Em Wed, Nov 12, 2014 at 06:05:18PM -0800, Andi Kleen escreveu:

Quoted 9 lines

[Reworks to address all the review feedback. Rebased to latest tree] [Just a repost after a rebase]
[Even more review feedback and some bugs addressed.] [Only port to changes in perf/core. No other changes.] [Rebase to latest perf/core]
[Another rebase. No changes]

This patchkit implements lbr-as-callgraphs in per freport, as an alternative way to present LBR information.

Ok, I have this in my perf/core branch, but I need to test it further, as I couldn't get the output that appears on some of the changelogs.

If you could take a look at

Quoted 6 lines

Quoted 4 lines

git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux perf/core

To see if I made some mistake, that would be of help,

I'm getting compile error for DEBUG=1

looks like the BUILD_BUG_ON_MSG does not work correctly with -O6 we use

Hi Jiri,

Quoted 20 lines · Jiri Olsa

Quoted 19 lines · Jiri Olsa

Quoted 18 lines · Arnaldo Carvalho de Melo

Em Wed, Nov 12, 2014 at 06:05:18PM -0800, Andi Kleen escreveu:

Quoted 9 lines

[Reworks to address all the review feedback. Rebased to latest tree] [Just a repost after a rebase]
[Even more review feedback and some bugs addressed.] [Only port to changes in perf/core. No other changes.] [Rebase to latest perf/core]
[Another rebase. No changes]

This patchkit implements lbr-as-callgraphs in per freport, as an alternative way to present LBR information.

Ok, I have this in my perf/core branch, but I need to test it further, as I couldn't get the output that appears on some of the changelogs.

If you could take a look at

git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux perf/core

Quoted 6 lines

Quoted 4 lines

Quoted 2 lines

To see if I made some mistake, that would be of help,

I'm getting compile error for DEBUG=1

looks like the BUILD_BUG_ON_MSG does not work correctly with -O6 we use

Nope, DEBUG=1 prevents -O6 from applied. we have below in config/Makefile:

ifndef DEBUG

    DEBUG := 0

endif

  ifeq ($(DEBUG),0)
    CFLAGS += -O6
  endif

Looking at include/linux/bug.h, BUILD_BUG_ON is guarded under __OPTIMIZE__ but BUILD_BUG_ON_MSG is not. What about changing it to BUILD_BUG_ON then?

Quoted 23 lines · Namhyung Kim

Hi Jiri,

Quoted 20 lines · Jiri Olsa

Quoted 19 lines · Jiri Olsa

Quoted 18 lines · Arnaldo Carvalho de Melo

Em Wed, Nov 12, 2014 at 06:05:18PM -0800, Andi Kleen escreveu:

Quoted 9 lines

[Reworks to address all the review feedback. Rebased to latest tree] [Just a repost after a rebase]
[Even more review feedback and some bugs addressed.] [Only port to changes in perf/core. No other changes.] [Rebase to latest perf/core]
[Another rebase. No changes]

This patchkit implements lbr-as-callgraphs in per freport, as an alternative way to present LBR information.

Ok, I have this in my perf/core branch, but I need to test it further, as I couldn't get the output that appears on some of the changelogs.

If you could take a look at

git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux perf/core

Quoted 8 lines

Quoted 6 lines

Quoted 4 lines

Quoted 2 lines

To see if I made some mistake, that would be of help,

I'm getting compile error for DEBUG=1

looks like the BUILD_BUG_ON_MSG does not work correctly with -O6 we use

Nope, DEBUG=1 prevents -O6 from applied. we have below in config/Makefile:

right.. the other way around ;))

Quoted 10 lines

ifndef DEBUG

    DEBUG := 0

endif

  ifeq ($(DEBUG),0)
    CFLAGS += -O6
  endif

Quoted 3 lines

Looking at include/linux/bug.h, BUILD_BUG_ON is guarded under __OPTIMIZE__ but BUILD_BUG_ON_MSG is not. What about changing it to BUILD_BUG_ON then?

sounds gut

Quoted 3 lines

Quoted 1 line

BUILD_BUG_ON then?

sounds gut

hum, acme/perf/core changed and so has the compile error ;-) we dont overload the <linux/bug.h>, so the kernel one got included, which is wrong.. attached patch fixes that

Em Wed, Nov 19, 2014 at 11:54:50AM +0100, Jiri Olsa escreveu:

Quoted 7 lines

Quoted 3 lines

Quoted 1 line

BUILD_BUG_ON then?

sounds gut

hum, acme/perf/core changed and so has the compile error ;-) we dont overload the <linux/bug.h>, so the kernel one got included, which is wrong.. attached patch fixes that

I had fixed this but not force pushed out, sorry.

Now I mistakenly tried running:

perf report --stdio --no-children --branch-history

on a file that has no BRANCH_STACK, i.e. a perf.data file on a wrong directory since I'm comparing the output of --stdio, --tui and --gtk, since it looks --gtk is wrong, still unsure about what the problem is in that case, but stumbled on:

Em Wed, Nov 19, 2014 at 11:10:27AM -0300, Arnaldo Carvalho de Melo escreveu:

Quoted 16 lines

Em Wed, Nov 19, 2014 at 11:54:50AM +0100, Jiri Olsa escreveu:

Quoted 7 lines

Quoted 3 lines

Quoted 1 line

BUILD_BUG_ON then?

sounds gut

hum, acme/perf/core changed and so has the compile error ;-) we dont overload the <linux/bug.h>, so the kernel one got included, which is wrong.. attached patch fixes that

I had fixed this but not force pushed out, sorry.

Now I mistakenly tried running:

perf report --stdio --no-children --branch-history

on a file that has no BRANCH_STACK, i.e. a perf.data file on a wrong

Quoted 4 lines

directory since I'm comparing the output of --stdio, --tui and --gtk, since it looks --gtk is wrong, still unsure about what the problem is in that case, but stumbled on:

I need to investigate this further, so I created a perf/branch-history branch that has the patches I need to test more rebased on top of my perf/core branch I just pushed out to Ingo.

Quoted 12 lines

Em Wed, Nov 19, 2014 at 11:10:27AM -0300, Arnaldo Carvalho de Melo escreveu:

Quoted 11 lines

Em Wed, Nov 19, 2014 at 11:54:50AM +0100, Jiri Olsa escreveu:

Quoted 7 lines

Quoted 3 lines

Quoted 1 line

BUILD_BUG_ON then?

sounds gut

hum, acme/perf/core changed and so has the compile error ;-) we dont overload the <linux/bug.h>, so the kernel one got included, which is wrong.. attached patch fixes that

I had fixed this but not force pushed out, sorry.

Quoted 5 lines

Quoted 5 lines

Now I mistakenly tried running:

perf report --stdio --no-children --branch-history

on a file that has no BRANCH_STACK, i.e. a perf.data file on a wrong

It works with -g.

Without -g it will just give an error message. I think that is ok, isn't it?

Quoted 5 lines

Quoted 4 lines

directory since I'm comparing the output of --stdio, --tui and --gtk, since it looks --gtk is wrong, still unsure about what the problem is in that case, but stumbled on:

Quoted 3 lines

I need to investigate this further, so I created a perf/branch-history branch that has the patches I need to test more rebased on top of my perf/core branch I just pushed out to Ingo.

I tested --gtk and I don't see any differences to the console mode with --branch-history. What problem do you see?

Em Wed, Nov 19, 2014 at 10:48:22PM +0100, Andi Kleen escreveu:

Quoted 15 lines · Arnaldo Carvalho de Melo

Quoted 14 lines

Em Wed, Nov 19, 2014 at 11:10:27AM -0300, Arnaldo Carvalho de Melo escreveu:

Quoted 13 lines

Em Wed, Nov 19, 2014 at 11:54:50AM +0100, Jiri Olsa escreveu:

Quoted 7 lines

Quoted 3 lines

Quoted 1 line

BUILD_BUG_ON then?

sounds gut

hum, acme/perf/core changed and so has the compile error ;-) we dont overload the <linux/bug.h>, so the kernel one got included, which is wrong.. attached patch fixes that

I had fixed this but not force pushed out, sorry.

Now I mistakenly tried running:

Quoted 5 lines

Quoted 3 lines

Quoted 3 lines

perf report --stdio --no-children --branch-history

on a file that has no BRANCH_STACK, i.e. a perf.data file on a wrong

It works with -g.

What works with -g? perf report?

Quoted 14 lines

Without -g it will just give an error message. I think that is ok, isn't it?

Quoted 8 lines

Quoted 4 lines

directory since I'm comparing the output of --stdio, --tui and --gtk, since it looks --gtk is wrong, still unsure about what the problem is in that case, but stumbled on:

I need to investigate this further, so I created a perf/branch-history branch that has the patches I need to test more rebased on top of my perf/core branch I just pushed out to Ingo.

Quoted 2 lines

I tested --gtk and I don't see any differences to the console mode with --branch-history. What problem do you see?

The difference is with --tui, but I haven't checked if this is a problem introduced by your patchkit or if this is something that was there before it was applied.

Em Wed, Nov 19, 2014 at 10:48:22PM +0100, Andi Kleen escreveu:

Quoted 7 lines

Quoted 7 lines

Quoted 3 lines

directory since I'm comparing the output of --stdio, --tui and --gtk, since it looks --gtk is wrong, still unsure about what the problem is in that case, but stumbled on:

I need to investigate this further, so I created a perf/branch-history branch that has the patches I need to test more rebased on top of my perf/core branch I just pushed out to Ingo.

Quoted 2 lines

I tested --gtk and I don't see any differences to the console mode with --branch-history. What problem do you see?

The difference is with --tui, but I haven't checked if this is a problem introduced by your patchkit or if this is something that was there before it was applied.

     f1 tcall.c:9
     main tcall.c:17
     main tcall.c:17
     main tcall.c:16
     main tcall.c:16
     f1 tcall.c:12
     f1 tcall.c:12
     f2 tcall.c:6
     f2 tcall.c:4
     f1 tcall.c:11
     f1 tcall.c:11
     f2 tcall.c:6
     f2 tcall.c:4
     f1 tcall.c:10
     f1 tcall.c:9
     main tcall.c:17

<SNIP>

Do you see the diff? The 87.65% and 12.35% doesn't appear on the --tui output.

Quoted 16 lines

     f1 tcall.c:9
     main tcall.c:17
     main tcall.c:17
     main tcall.c:16
     main tcall.c:16
     f1 tcall.c:12
     f1 tcall.c:12
     f2 tcall.c:6
     f2 tcall.c:4
     f1 tcall.c:11
     f1 tcall.c:11
     f2 tcall.c:6
     f2 tcall.c:4
     f1 tcall.c:10
     f1 tcall.c:9
     main tcall.c:17

Quoted 5 lines

<SNIP>

Do you see the diff? The 87.65% and 12.35% doesn't appear on the --tui output.

I see the problem. It's some issue in hist_browser__show_callchain. --stdio doesn't show it because it doesn't seem to use that (?)

With this patch it shows percent for the first entry

(quoted diff) +1 -1

@@ -791,7 +791,7 @@ static int hist_browser__show_entry(struct hist_browser *browser,
                };
 
                printed += hist_browser__show_callchain(browser,
-                                       &entry->sorted_chain, 1, row, total,
+                                       &entry->sorted_chain, 2, row, total,
                                        hist_browser__show_callchain_entry, &arg,
                                        hist_browser__check_output_full);
 

But the numbers are still different from what --stdio outputs, so there are some deeper issues.

I doubt I caused this, probably some latent bug that just got triggered.

Namhyung?

Segmentation fault (core dumped)
[root@zoo ~]#

Rebuilding with DEBUG=1 I get this backtrace:

Using host libthread_db library "/lib64/libthread_db.so.1".
Core was generated by `perf report --stdio --no-children --branch-history'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0 0x000000000053ab10 in read_unsigned_leb128 ()
Missing separate debuginfos, use: debuginfo-install bzip2-libs-1.0.6-9.fc20.x86_64 elfutils-libelf-0.160-1.fc20.x86_64 elfutils-libs-0.160-1.fc20.x86_64 libunwind-1.1-3.fc20.x86_64 nss-softokn-freebl-3.17.2-1.fc20.x86_64 numactl-libs-2.0.9-2.fc20.x86_64 slang-2.2.4-11.fc20.x86_64 xz-libs-5.1.2-12alpha.fc20.x86_64 (gdb) bt

#0  0x000000000053ab10 in read_unsigned_leb128 ()
#1  0x00000000005485d7 in find_abstract_instance_name.isra ()
#2  0x0000000000548756 in find_abstract_instance_name.isra ()
#3  0x0000000000548756 in find_abstract_instance_name.isra ()
#4  0x0000000000548d31 in scan_unit_for_symbols ()
#5  0x00000000005496c9 in comp_unit_find_nearest_line ()
#6  0x000000000054a6ca in find_line.part ()
#7  0x00000000005606ca in _bfd_elf_find_nearest_line_discriminator ()
#8  0x00000000005607db in _bfd_elf_find_nearest_line ()
#9  0x00000000004dabf1 in find_address_in_section (abfd=0xfd522f0, section=0xe8be528, data=0xfa50c30) at util/srcline.c:100

#10 0x000000000053cbdc in bfd_map_over_sections ()
#11 0x00000000004dae84 in addr2line (dso_name=0xe89fe70 "/usr/lib/debug/usr/lib64/firefox/libxul.so.debug", addr=24667432, file=0x7fff3981f9c0, line=0x7fff3981f9bc, dso=0x22a0b50) at util/srcline.c:168 #12 0x00000000004db017 in get_srcline (dso=0x22a0b50, addr=24667432, sym=0xf6b93f0, show_sym=true) at util/srcline.c:276

Quoted 4 lines

Segmentation fault (core dumped)
[root@zoo ~]#

Rebuilding with DEBUG=1 I get this backtrace:

Ok it crashes inside libbfd while resolving the line. Not much I can do about it.

Could file a bug with the binutils people, if you have a test case?

Quoted 20 lines

Using host libthread_db library "/lib64/libthread_db.so.1".
Core was generated by `perf report --stdio --no-children --branch-history'.
Program terminated with signal SIGSEGV, Segmentation fault.
#0 0x000000000053ab10 in read_unsigned_leb128 ()
Missing separate debuginfos, use: debuginfo-install bzip2-libs-1.0.6-9.fc20.x86_64 elfutils-libelf-0.160-1.fc20.x86_64 elfutils-libs-0.160-1.fc20.x86_64 libunwind-1.1-3.fc20.x86_64 nss-softokn-freebl-3.17.2-1.fc20.x86_64 numactl-libs-2.0.9-2.fc20.x86_64 slang-2.2.4-11.fc20.x86_64 xz-libs-5.1.2-12alpha.fc20.x86_64 (gdb) bt

#0  0x000000000053ab10 in read_unsigned_leb128 ()
#1  0x00000000005485d7 in find_abstract_instance_name.isra ()
#2  0x0000000000548756 in find_abstract_instance_name.isra ()
#3  0x0000000000548756 in find_abstract_instance_name.isra ()
#4  0x0000000000548d31 in scan_unit_for_symbols ()
#5  0x00000000005496c9 in comp_unit_find_nearest_line ()
#6  0x000000000054a6ca in find_line.part ()
#7  0x00000000005606ca in _bfd_elf_find_nearest_line_discriminator ()
#8  0x00000000005607db in _bfd_elf_find_nearest_line ()
#9  0x00000000004dabf1 in find_address_in_section (abfd=0xfd522f0, section=0xe8be528, data=0xfa50c30) at util/srcline.c:100

#10 0x000000000053cbdc in bfd_map_over_sections ()
#11 0x00000000004dae84 in addr2line (dso_name=0xe89fe70 "/usr/lib/debug/usr/lib64/firefox/libxul.so.debug", addr=24667432, file=0x7fff3981f9c0, line=0x7fff3981f9bc, dso=0x22a0b50) at util/srcline.c:168 #12 0x00000000004db017 in get_srcline (dso=0x22a0b50, addr=24667432, sym=0xf6b93f0, show_sym=true) at util/srcline.c:276

Quoted 16 lines · Arnaldo Carvalho de Melo

Quoted 15 lines

Em Wed, Nov 12, 2014 at 06:05:18PM -0800, Andi Kleen escreveu:

Quoted 9 lines

[Reworks to address all the review feedback. Rebased to latest tree] [Just a repost after a rebase]
[Even more review feedback and some bugs addressed.] [Only port to changes in perf/core. No other changes.] [Rebase to latest perf/core]
[Another rebase. No changes]

This patchkit implements lbr-as-callgraphs in per freport, as an alternative way to present LBR information.

Ok, I have this in my perf/core branch, but I need to test it further, as I couldn't get the output that appears on some of the changelogs.

If you could take a look at

Quoted 5 lines

Quoted 3 lines

git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux perf/core

To see if I made some mistake, that would be of help,

I'm getting compile error for DEBUG=1

looks like the BUILD_BUG_ON_MSG does not work correctly with -O6 we use

Quoted 3 lines

Quoted 1 line

I'm getting compile error for DEBUG=1

looks like the BUILD_BUG_ON_MSG does not work correctly with -O6 we use

Yeah, I'll probably just take the brute force approach Andi originally used and switch to BUILD_BUG_ON_MSG once we get it working in the tools/ environment, i.e. using -O6, etc.