From: sashiko-bot@kernel.org
To: "Eduard Zateev" <hackerowskiy@gmail.com>, bpf@vger.kernel.org
Subject: Re: [PATCH] bpftool: fix line info in multi-function CFG dumps
Date: Sat, 24 Oct 2026 06:38:46 +0000 [thread overview]
Message-ID: <sashiko-outbox-183570@kernel.org> (raw)
In-Reply-To: <20261024062329.264086-1-hackerowskiy@gmail.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] bpftool: function-relative bpf_func_info offset in dump_xlated_for_graph()
--
commit 880c182e492fbe51e0cdd7cbcdc7fcfdb2fe9c94
Author: Eduard Zateev <hackerowskiy@gmail.com>
bpftool: fix line info in multi-function CFG dumps
This commit passes the program start pointer into the CFG graph dumper so that
BTF line-info lookups and displayed instruction indices use the global
instruction offset rather than a function-relative offset, while keeping
function-info matching relative to each function. It also adds a BPF selftest
for multi-function visual CFG output.
Link: https://github.com/libbpf/bpftool/issues/178
> diff --git a/tools/bpf/bpftool/cfg.c b/tools/bpf/bpftool/cfg.c
> index e3785f9a697de..65ec45469743b 100644
> --- a/tools/bpf/bpftool/cfg.c
> +++ b/tools/bpf/bpftool/cfg.c
> @@ -383,7 +383,7 @@ static void cfg_destroy(struct cfg *cfg)
>
> static void
> draw_bb_node(struct func_node *func, struct bb_node *bb, struct dump_data *dd,
> - bool opcodes, bool linum)
> + struct bpf_insn *prog_start, bool opcodes, bool linum)
> {
> const char *shape;
>
> @@ -400,11 +400,11 @@ draw_bb_node(struct func_node *func, struct bb_node *bb, struct dump_data *dd,
> } else if (bb->idx == EXIT_BLOCK_INDEX) {
> printf("EXIT");
> } else {
> - unsigned int start_idx;
> + unsigned int start_idx = bb->head - func->start;
> +
> printf("{\\\n");
> - start_idx = bb->head - func->start;
> dump_xlated_for_graph(dd, bb->head, bb->tail, start_idx,
> - opcodes, linum);
> + prog_start, opcodes, linum);
> printf("}");
> }
>
[ ... ]
> diff --git a/tools/bpf/bpftool/xlated_dumper.c b/tools/bpf/bpftool/xlated_dumper.c
> index 5579173a61e3b..847241bbe91e2 100644
> --- a/tools/bpf/bpftool/xlated_dumper.c
> +++ b/tools/bpf/bpftool/xlated_dumper.c
> @@ -353,7 +353,7 @@ 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, struct bpf_insn *prog_start,
> bool opcodes, bool linum)
> {
> const struct bpf_insn_cbs cbs = {
> @@ -374,6 +374,7 @@ void dump_xlated_for_graph(struct dump_data *dd, void *buf_start, void *buf_end,
>
> for (; cur <= insn_end; cur++) {
> unsigned int insn_off;
> + unsigned int linfo_offset;
>
> if (double_insn) {
> double_insn = false;
> @@ -381,7 +382,8 @@ void dump_xlated_for_graph(struct dump_data *dd, void *buf_start, void *buf_end,
> }
> double_insn = cur->code == (BPF_LD | BPF_IMM | BPF_DW);
>
> - insn_off = (unsigned int)(cur - insn_start + start_idx);
> + insn_off = (unsigned int)(cur - insn_start) + start_idx;
> + linfo_offset = (unsigned int)(cur - prog_start);
> if (btf && record) {
> if (record->insn_off == insn_off) {
[Severity: Medium]
Should struct bpf_func_info matching in dump_xlated_for_graph() also use the
global instruction offset from the start of the program rather than the
function-relative insn_off?
In the kernel verifier and in dump_xlated_plain(), record->insn_off is the
global instruction offset from the start of the whole program (0 for the main
program, and the subprogram start offset for each subprogram).
In dump_xlated_for_graph(), record is initialized to dd->func_info at the
start of each basic block:
struct bpf_func_info *record = dd->func_info;
...
insn_off = (unsigned int)(cur - insn_start) + start_idx;
linfo_offset = (unsigned int)(cur - prog_start);
if (btf && record) {
if (record->insn_off == insn_off) {
btf_dumper_type_only(btf, record->type_id,
func_sig,
sizeof(func_sig));
if (func_sig[0] != '\0')
printf("; %s:\\l\\\n", func_sig);
record = (void *)record + dd->finfo_rec_size;
}
}
Because draw_bb_node() computes start_idx as bb->head - func->start, every
subprogram's entry basic block starts at insn_off == 0. When
dump_xlated_cfg() -> cfg_dump() -> func_output_bb_def() -> draw_bb_node() ->
dump_xlated_for_graph() runs on the second function (cluster_1), insn_off == 0
matches func_info[0] (record->insn_off == 0) and prints the first function's
prototype at the entry of the second function.
Then record advances to func_info[1], whose record->insn_off is the global
instruction offset of the second function (for example, 2 in bpftool_cfg.c).
When the loop reaches function-relative insn_off == 2 inside the second
function's entry block (global instruction 4), record->insn_off == insn_off
matches mid-block and emits the second function's prototype before instruction
4 instead of instruction 2 (or omits it if the entry basic block is shorter
than the global offset).
If draw_bb_node() passes start_idx as bb->head - prog_start (or if
dump_xlated_for_graph() computes the global offset from prog_start and walks
dd->func_info up to that offset), wouldn't that fix the function prototype
annotations in cluster_1 as well and avoid needing both start_idx and
prog_start?
--
Sashiko AI review · https://sashiko.dev/#/patchset/20261024062329.264086-1-hackerowskiy@gmail.com?part=1
next prev parent reply other threads:[~2026-10-24 6:38 UTC|newest]
Thread overview: 4+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-24 6:23 [PATCH] bpftool: fix line info in multi-function CFG dumps Eduard Zateev
2026-10-24 6:38 ` sashiko-bot [this message]
2026-10-24 7:05 ` bot+bpf-ci
2026-10-26 10:58 ` 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=sashiko-outbox-183570@kernel.org \
--to=sashiko-bot@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=hackerowskiy@gmail.com \
--cc=sashiko-reviews@lists.linux.dev \
/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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.