bpf.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Quentin Monnet <quentin@isovalent.com>
To: Eduard Zingerman <eddyz87@gmail.com>,
	Alexei Starovoitov <ast@kernel.org>,
	Daniel Borkmann <daniel@iogearbox.net>,
	Andrii Nakryiko <andrii@kernel.org>
Cc: Martin KaFai Lau <kafai@fb.com>, Song Liu <songliubraving@fb.com>,
	Yonghong Song <yhs@fb.com>,
	John Fastabend <john.fastabend@gmail.com>,
	KP Singh <kpsingh@kernel.org>,
	Stanislav Fomichev <sdf@google.com>, Hao Luo <haoluo@google.com>,
	Jiri Olsa <jolsa@kernel.org>,
	bpf@vger.kernel.org
Subject: Re: [PATCH bpf-next v2 5/5] bpftool: Support printing opcodes and source file references in CFG
Date: Fri, 31 Mar 2023 15:52:50 +0100	[thread overview]
Message-ID: <899fb41c-2bc4-c60f-c83b-4eb5c348e711@isovalent.com> (raw)
In-Reply-To: <fa28d05a6a123aea329a02ac666dbb18e7c5f519.camel@gmail.com>

2023-03-27 20:04 UTC+0300 ~ Eduard Zingerman <eddyz87@gmail.com>
> On Mon, 2023-03-27 at 12:06 +0100, Quentin Monnet wrote:
>> Add support for displaying opcodes or/and file references (filepath,
>> line and column numbers) when dumping the control flow graphs of loaded
>> BPF programs with bpftool.
>>
>> Signed-off-by: Quentin Monnet <quentin@isovalent.com>
>> Acked-by: Stanislav Fomichev <sdf@google.com>
>> ---
>>  tools/bpf/bpftool/btf_dumper.c    | 19 ++++++++++++++++++-
>>  tools/bpf/bpftool/cfg.c           | 22 ++++++++++++++--------
>>  tools/bpf/bpftool/cfg.h           |  3 ++-
>>  tools/bpf/bpftool/main.h          |  2 +-
>>  tools/bpf/bpftool/prog.c          |  2 +-
>>  tools/bpf/bpftool/xlated_dumper.c | 15 +++++++++++++--
>>  tools/bpf/bpftool/xlated_dumper.h |  3 ++-
>>  7 files changed, 51 insertions(+), 15 deletions(-)
>>
>> diff --git a/tools/bpf/bpftool/btf_dumper.c b/tools/bpf/bpftool/btf_dumper.c
>> index 8bfc1b69497d..24835c3f9a1c 100644
>> --- a/tools/bpf/bpftool/btf_dumper.c
>> +++ b/tools/bpf/bpftool/btf_dumper.c
>> @@ -841,7 +841,7 @@ static void dotlabel_puts(const char *s)
>>  }
>>  
>>  void btf_dump_linfo_dotlabel(const struct btf *btf,
>> -			     const struct bpf_line_info *linfo)
>> +			     const struct bpf_line_info *linfo, bool linum)
>>  {
>>  	const char *line = btf__name_by_offset(btf, linfo->line_off);
>>  
>> @@ -849,6 +849,23 @@ void btf_dump_linfo_dotlabel(const struct btf *btf,
>>  		return;
>>  	line = ltrim(line);
>>  
>> +	if (linum) {
>> +		const char *file = btf__name_by_offset(btf, linfo->file_name_off);
>> +
>> +		/* More forgiving on file because linum option is
>> +		 * expected to provide more info than the already
>> +		 * available src line.
>> +		 */
>> +		if (!file)
>> +			file = "";
>> +
>> +		printf("; [file:");
>> +		dotlabel_puts(file);
>> +		printf("line_num:%u line_col:%u]\\l\\\n",
> 
> Space between file name and 'line_num' is missing.

My bad, thanks!

> 
> Also, at-least for BPF test-cases the labels might become quite long,
> which makes graph unnecessarily wide, e.g.:
> 
>   ; [file:/home/eddy/work/bpf-next/tools/testing/selftests/bpf/progs/bpf_flow.cline_num:97 line_col:34]\l\
> 
> The file names are encoded in full during compilation, but maybe
> shorten long file names by removing some preceding levels
> (and use shorter tags 'line:', 'col:', is 'file:' tag necessary at all?).
> For example:
> 
>   ; [.../progs/bpf_flow.c line:97 col:34]\l\.

I thought about that but was unsure. But yeah, I suppose the risk of
users getting confused about where the file is located is limited,
especially given that we still have regular program dump that will keep
the full path. OK I'll look into that for the next version.

> 
>> +		       BPF_LINE_INFO_LINE_NUM(linfo->line_col),
>> +		       BPF_LINE_INFO_LINE_COL(linfo->line_col));
>> +	}
>> +
>>  	printf("; ");
>>  	dotlabel_puts(line);
>>  	printf("\\l\\\n");
>> diff --git a/tools/bpf/bpftool/cfg.c b/tools/bpf/bpftool/cfg.c
>> index 9fdc1f0cdd6e..eec437cca2ea 100644
>> --- a/tools/bpf/bpftool/cfg.c
>> +++ b/tools/bpf/bpftool/cfg.c
>> @@ -381,7 +381,8 @@ static void cfg_destroy(struct cfg *cfg)
>>  }
>>  
>>  static void
>> -draw_bb_node(struct func_node *func, struct bb_node *bb, struct dump_data *dd)
>> +draw_bb_node(struct func_node *func, struct bb_node *bb, struct dump_data *dd,
>> +	     bool opcodes, bool linum)
>>  {
>>  	const char *shape;
>>  
>> @@ -401,7 +402,8 @@ draw_bb_node(struct func_node *func, struct bb_node *bb, struct dump_data *dd)
>>  		unsigned int start_idx;
>>  		printf("{\\\n");
>>  		start_idx = bb->head - func->start;
>> -		dump_xlated_for_graph(dd, bb->head, bb->tail, start_idx);
>> +		dump_xlated_for_graph(dd, bb->head, bb->tail, start_idx,
>> +				      opcodes, linum);
>>  		printf("}");
>>  	}
>>  
>> @@ -427,12 +429,14 @@ static void draw_bb_succ_edges(struct func_node *func, struct bb_node *bb)
>>  	}
>>  }
>>  
>> -static void func_output_bb_def(struct func_node *func, struct dump_data *dd)
>> +static void
>> +func_output_bb_def(struct func_node *func, struct dump_data *dd,
>> +		   bool opcodes, bool linum)
>>  {
>>  	struct bb_node *bb;
>>  
>>  	list_for_each_entry(bb, &func->bbs, l) {
>> -		draw_bb_node(func, bb, dd);
>> +		draw_bb_node(func, bb, dd, opcodes, linum);
>>  	}
>>  }
>>  
>> @@ -452,7 +456,8 @@ static void func_output_edges(struct func_node *func)
>>  	       func_idx, ENTRY_BLOCK_INDEX, func_idx, EXIT_BLOCK_INDEX);
>>  }
>>  
>> -static void cfg_dump(struct cfg *cfg, struct dump_data *dd)
>> +static void
>> +cfg_dump(struct cfg *cfg, struct dump_data *dd, bool opcodes, bool linum)
>>  {
>>  	struct func_node *func;
>>  
>> @@ -460,14 +465,15 @@ static void cfg_dump(struct cfg *cfg, struct dump_data *dd)
>>  	list_for_each_entry(func, &cfg->funcs, l) {
>>  		printf("subgraph \"cluster_%d\" {\n\tstyle=\"dashed\";\n\tcolor=\"black\";\n\tlabel=\"func_%d ()\";\n",
>>  		       func->idx, func->idx);
>> -		func_output_bb_def(func, dd);
>> +		func_output_bb_def(func, dd, opcodes, linum);
>>  		func_output_edges(func);
>>  		printf("}\n");
>>  	}
>>  	printf("}\n");
>>  }
>>  
>> -void dump_xlated_cfg(struct dump_data *dd, void *buf, unsigned int len)
>> +void dump_xlated_cfg(struct dump_data *dd, void *buf, unsigned int len,
>> +		     bool opcodes, bool linum)
>>  {
>>  	struct bpf_insn *insn = buf;
>>  	struct cfg cfg;
>> @@ -476,7 +482,7 @@ void dump_xlated_cfg(struct dump_data *dd, void *buf, unsigned int len)
>>  	if (cfg_build(&cfg, insn, len))
>>  		return;
>>  
>> -	cfg_dump(&cfg, dd);
>> +	cfg_dump(&cfg, dd, opcodes, linum);
>>  
>>  	cfg_destroy(&cfg);
>>  }
>> diff --git a/tools/bpf/bpftool/cfg.h b/tools/bpf/bpftool/cfg.h
>> index 909d17e6d4c2..b3793f4e1783 100644
>> --- a/tools/bpf/bpftool/cfg.h
>> +++ b/tools/bpf/bpftool/cfg.h
>> @@ -6,6 +6,7 @@
>>  
>>  #include "xlated_dumper.h"
>>  
>> -void dump_xlated_cfg(struct dump_data *dd, void *buf, unsigned int len);
>> +void dump_xlated_cfg(struct dump_data *dd, void *buf, unsigned int len,
>> +		     bool opcodes, bool linum);
>>  
>>  #endif /* __BPF_TOOL_CFG_H */
>> diff --git a/tools/bpf/bpftool/main.h b/tools/bpf/bpftool/main.h
>> index e9ee514b22d4..00d11ca6d3f2 100644
>> --- a/tools/bpf/bpftool/main.h
>> +++ b/tools/bpf/bpftool/main.h
>> @@ -230,7 +230,7 @@ void btf_dump_linfo_plain(const struct btf *btf,
>>  void btf_dump_linfo_json(const struct btf *btf,
>>  			 const struct bpf_line_info *linfo, bool linum);
>>  void btf_dump_linfo_dotlabel(const struct btf *btf,
>> -			     const struct bpf_line_info *linfo);
>> +			     const struct bpf_line_info *linfo, bool linum);
>>  
>>  struct nlattr;
>>  struct ifinfomsg;
>> diff --git a/tools/bpf/bpftool/prog.c b/tools/bpf/bpftool/prog.c
>> index 567ac37dbd86..848f57a7d762 100644
>> --- a/tools/bpf/bpftool/prog.c
>> +++ b/tools/bpf/bpftool/prog.c
>> @@ -854,7 +854,7 @@ prog_dump(struct bpf_prog_info *info, enum dump_mode mode,
>>  		else if (json_output)
>>  			dump_xlated_json(&dd, buf, member_len, opcodes, linum);
>>  		else if (visual)
>> -			dump_xlated_cfg(&dd, buf, member_len);
>> +			dump_xlated_cfg(&dd, buf, member_len, opcodes, linum);
>>  		else
>>  			dump_xlated_plain(&dd, buf, member_len, opcodes, linum);
>>  		kernel_syms_destroy(&dd);
>> diff --git a/tools/bpf/bpftool/xlated_dumper.c b/tools/bpf/bpftool/xlated_dumper.c
>> index 5fbe94aa8589..c5e03833fadf 100644
>> --- a/tools/bpf/bpftool/xlated_dumper.c
>> +++ b/tools/bpf/bpftool/xlated_dumper.c
>> @@ -361,7 +361,8 @@ void dump_xlated_plain(struct dump_data *dd, void *buf, unsigned int len,
>>  }
>>  
>>  void dump_xlated_for_graph(struct dump_data *dd, void *buf_start, void *buf_end,
>> -			   unsigned int start_idx)
>> +			   unsigned int start_idx,
>> +			   bool opcodes, bool linum)
>>  {
>>  	const struct bpf_insn_cbs cbs = {
>>  		.cb_print	= print_insn_for_graph,
>> @@ -405,7 +406,7 @@ void dump_xlated_for_graph(struct dump_data *dd, void *buf_start, void *buf_end,
>>  
>>  			linfo = bpf_prog_linfo__lfind(prog_linfo, insn_off, 0);
>>  			if (linfo && linfo != last_linfo) {
>> -				btf_dump_linfo_dotlabel(btf, linfo);
>> +				btf_dump_linfo_dotlabel(btf, linfo, linum);
>>  				last_linfo = linfo;
>>  			}
>>  		}
>> @@ -413,6 +414,16 @@ void dump_xlated_for_graph(struct dump_data *dd, void *buf_start, void *buf_end,
>>  		printf("%d: ", insn_off);
>>  		print_bpf_insn(&cbs, cur, true);
>>  
>> +		if (opcodes) {
>> +			printf("       ");
> 
> These spaces are treated as a single space by the dot renderer, as [1]
> says: "Spaces are interpreted as separators between tokens, so they
> must be escaped if you want spaces in the text."
> 
> [1] https://graphviz.org/doc/info/shapes.html#record

I noticed, I kept the multiple spaces to make the DOT output slightly
more readable. But it would maybe make sense to indent more in the graph
as well, if it doesn't make opcode sequences wider than instructions.
I'll have a look at this.

  reply	other threads:[~2023-03-31 14:53 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-03-27 11:06 [PATCH bpf-next v2 0/5] bpftool: Add inline annotations when dumping program CFGs Quentin Monnet
2023-03-27 11:06 ` [PATCH bpf-next v2 1/5] bpftool: Fix documentation about line info display for prog dumps Quentin Monnet
2023-03-27 11:06 ` [PATCH bpf-next v2 2/5] bpftool: Fix bug for long instructions in program CFG dumps Quentin Monnet
2023-03-27 11:06 ` [PATCH bpf-next v2 3/5] bpftool: Support inline annotations when dumping the CFG of a program Quentin Monnet
2023-03-27 17:02   ` Eduard Zingerman
2023-03-31 14:52     ` Quentin Monnet
2023-03-27 11:06 ` [PATCH bpf-next v2 4/5] bpftool: Support "opcodes", "linum", "visual" simultaneously Quentin Monnet
2023-03-27 11:06 ` [PATCH bpf-next v2 5/5] bpftool: Support printing opcodes and source file references in CFG Quentin Monnet
2023-03-27 17:04   ` Eduard Zingerman
2023-03-31 14:52     ` Quentin Monnet [this message]
2023-03-31 15:03       ` Eduard Zingerman
2023-03-27 17:56 ` [PATCH bpf-next v2 0/5] bpftool: Add inline annotations when dumping program CFGs Eduard Zingerman
2023-03-31 14:53   ` Quentin Monnet

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=899fb41c-2bc4-c60f-c83b-4eb5c348e711@isovalent.com \
    --to=quentin@isovalent.com \
    --cc=andrii@kernel.org \
    --cc=ast@kernel.org \
    --cc=bpf@vger.kernel.org \
    --cc=daniel@iogearbox.net \
    --cc=eddyz87@gmail.com \
    --cc=haoluo@google.com \
    --cc=john.fastabend@gmail.com \
    --cc=jolsa@kernel.org \
    --cc=kafai@fb.com \
    --cc=kpsingh@kernel.org \
    --cc=sdf@google.com \
    --cc=songliubraving@fb.com \
    --cc=yhs@fb.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).