Re: [PATCH 0/2] scripts/gdb/symbols: make BPF debug info available to GDB

[Ilya Leoshkevich <iii@linux.ibm.com>]

On Thu, 2025-10-30 at 17:47 +0100, Jan Kiszka wrote:
> On 10.07.25 13:53, Ilya Leoshkevich wrote:
> > Hi,
> > 
> > This series greatly simplifies debugging BPF progs when using QEMU
> > gdbstub by providing symbol names, sizes, and line numbers to GDB.
> > 
> > Patch 1 adds radix tree iteration, which is necessary for parsing
> > prog_idr. Patch 2 is the actual implementation; its description
> > contains some details on how to use this.
> > 
> > Best regards,
> > Ilya
> > 
> > Ilya Leoshkevich (2):
> >   scripts/gdb/radix-tree: add lx-radix-tree-command
> >   scripts/gdb/symbols: make BPF debug info available to GDB
> > 
> >  scripts/gdb/linux/bpf.py          | 253
> > ++++++++++++++++++++++++++++++
> >  scripts/gdb/linux/constants.py.in |   3 +
> >  scripts/gdb/linux/radixtree.py    | 139 +++++++++++++++-
> >  scripts/gdb/linux/symbols.py      |  77 ++++++++-
> >  4 files changed, 462 insertions(+), 10 deletions(-)
> >  create mode 100644 scripts/gdb/linux/bpf.py
> > 
> 
> This wasn't picked up yet, right? Sorry for the late reply, my part
> of
> the "maintenance" here is best effort based.
> 
> Looks good to me regarding integration. I haven't tried it out, I'm
> just
> wondering if it has notable performance impact on starting gdb or
> interacting or when that could be the case. BPF programs are not
> uncommon in common setups today. But if you don't want to debug them,
> does this add unneeded overhead?
> 
> Otherwise, I think it could move forward if it still applies (which
> it
> likely does).
> 
> Jan

Thanks for taking a look!

I have to admit the performance implications are noticeable due to
having to spawn an external process for each BPF prog.

What do you think about hiding this behind `lx-symbols --bpf` flag?