[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <304f8078d9f6d523f4e334503384d7decd6f205d.camel@linux.ibm.com>
Date: Wed, 27 Aug 2025 13:26:14 +0200
From: Ilya Leoshkevich <iii@...ux.ibm.com>
To: Alexei Starovoitov <alexei.starovoitov@...il.com>
Cc: Alexei Starovoitov <ast@...nel.org>,
Daniel Borkmann
<daniel@...earbox.net>,
Andrii Nakryiko <andrii@...nel.org>,
Jan Kiszka
<jan.kiszka@...mens.com>,
Kieran Bingham <kbingham@...nel.org>,
LKML
<linux-kernel@...r.kernel.org>, bpf <bpf@...r.kernel.org>,
Heiko Carstens
<hca@...ux.ibm.com>,
Vasily Gorbik <gor@...ux.ibm.com>,
Alexander Gordeev
<agordeev@...ux.ibm.com>
Subject: Re: [PATCH 0/2] scripts/gdb/symbols: make BPF debug info available
to GDB
On Tue, 2025-08-05 at 09:48 -0700, Alexei Starovoitov wrote:
> On Tue, Aug 5, 2025 at 6:23 AM Ilya Leoshkevich <iii@...ux.ibm.com>
> wrote:
> >
> > On Thu, 2025-07-10 at 13:53 +0200, 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
> >
> > Gentle ping. Any opinions on whether this is valuable? Personally
> > I've
> > been using this for quite some time, and having source level
> > debugging
> > for BPF progs (even if variables can't be inspected) feels really
> > nice.
>
> Looks very useful to me.
> Not sure which git tree it should be routed to.
Thanks, glad to hear that!
I think it makes sense to route it via the Andrew Morton's tree, like
all the other GDB patches. IIUC the proposal to ask subsystems to
maintain GDB scripts relevant to them [1] didn't go anywhere.
[1]
https://lore.kernel.org/all/20250625231053.1134589-1-florian.fainelli@broadcom.com/
Powered by blists - more mailing lists