Re: [PATCH bpf-next] verifier: add prune points to live registers print

[Eduard Zingerman <eddyz87@gmail.com>]

On Mon, 2025-12-29 at 16:42 -0800, Alexei Starovoitov wrote:

[...]

> > Imo, it would be indeed more interesting to print where checkpoint
> > match had been attempted and why it failed, e.g. as I do in [1].
> > Here is a sample:
> > 
> >   cache miss at (140, 5389): frame=1, reg=0, spi=-1, loop=0 (cur: 1) vs (old: P0)
> >   from 5387 to 5389: frame1: R0=1 R1=0xffffffff ...
> > 
> > However, in the current form it slows down log level 2 output
> > significantly (~5 times). Okay for my debugging purposes but is not
> > good for upstream submission.
> > 
> > Thanks,
> > Eduard.
> > 
> > [1] https://github.com/kernel-patches/bpf/commit/65fcd66d03ad9d6979df79628e569b90563d5368
> 
> bpf_print_stack_state() refactor can land.
> While the rest potentially bpfvv can do.
> With log_level==2 all the previous paths through particular instruction
> will be in the log earlier, so I can imagine clicking on an insn
> and it will show current and all previous seen states.
> The verifier heuristic will drop some of them, so it will show more
> than actually known during the verification, but that's probably ok
> for debugging to see why states don't converge.
> bpfvv can make it easier to see the difference too instead of
> "frame=1, reg=0, spi=-1, loop=0 (cur: 1) vs (old: P0)"
> which is not easy to understand.
> Only after reading the diff I realized that reg R0 is the one
> that caused a mismatch.

In theory this can be handled in post-processing completely,
however I'd expect mirroring states-equal logic in bpfvv
(or any other tool) to be error prone. Which is very undesirable when
you are debugging. To make post-processing simpler I'd print:
- state id upon state creation
- state ids upon cache miss + register or spi number.

This way post-processing tool would only need to collect register
values for state ids in question.

Idk, not sure if any of this should be upstreamed, I'm fine with it
living in my debug branch. On the other hand, this might be useful for
people debugging 1M instruction issues, as I discussed with
Paul Chaignon and Shung-Hsi Yu at LPC.