Re: GDB variants accepting plugins (to the debugger) ?

[Matt Rice via Gdb <gdb@sourceware.org>]

On Fri, Jan 30, 2026 at 8:13 PM Tom Tromey <tom@tromey.com> wrote:
>
> >>>>> "Basile" == Basile Starynkevitch <basile@starynkevitch.net> writes:
>
> Basile> But coding manually a Python or Guile function for every
> Basile> important C++ classes of a software is very time consuming
>
> People often bring up the idea of using helper functions from the
> inferior for pretty-printing.  And maybe it can be done, kind of.
>
> But normally I push back against this idea for a few reasons.
>
> Internally this means making an inferior call in gdb.  But, gdb will use
> pretty-printers in all situations, including when unwinding the stack.
> This might work but its somewhat problematic to modify the stack while
> unwinding it.
>
> A related thing is that infcalls are sometimes very surprising.  For
> instance unless you mess with scheduler-locking, they cause other
> threads to run.  So, e.g., you could easily hit a breakpoint when
> printing a variable.
>
> Finally, this approach doesn't work at all for core files.
>
> A somewhat better idea is to have the compiler spit out some IR (wasm is
> often suggested) for these pretty-printers (and accessor functions and
> whatever else) and then have gdb run this.  This would be great but
> nobody has ever done the work... I did once consider doing this with a
> gcc plugin and having it generate Python but time is kind of short.
>

Yeah, I've thought wasm based pretty printers could be really cool,
especially for languages that already include debug based pretty printing code,
writing separate python pretty printers always seems like a bunch of extra work.

I suppose that one of the big hurdles is the standardization of something like
the component model, https://component-model.bytecodealliance.org/

I don't really know enough about wasi/the component model yet to know
how much of an impact
changes to the component model would impact gdb (because it currently
is a work in progress and isn't
fully standardized afaik so subject to changes).

Anyhow I would be/have been somewhat interesting in putting in
time/effort into working on this sort of building out wasm inspired by
parts of the python API, but it feels like you'd probably want to put
a big experimental sticker on it in the sense that it could end up
with some component-model upstream change which in theory may mean
that the bytecode compiled pretty printer may be tied to a particular
version gdb using whatever version of the component model. In the same
sense that we currently rely on a python version (with the difference
being that python is much longer history of stabilization than the
component model which)

So in my opinion there is a little more to it than just putting in the
work, there is a lot less prior art than python modules.
Perhaps it would be best to start out with configure option not
enabled by default, with the understanding that it is currently
experimental.
something like --enable-experimental-wasm-plugins or some such.
Anyhow I would be excited to play around with it some if there was a
roadmap for how we want to handle these issues...

> Basile> I regret that GDB 17.1 has not evolved into something similar to
> Basile> the old and unmaintained UPS open source debugger
> Basile> https://ups.sourceforge.net/ which sadly is not working on
> Basile> Linux/AMD-64 computers running a recent kernel 6.17 and and
> Basile> using recent libc and libstdc++
>
> I don't have much to suggest other than you can already do a lot with
> Python in gdb.  For instance I wrote a gdb GUI that runs in-process.
>
> Most of the gdb Python code you'll find in the wild will be
> pretty-printers; gdb has some of these for itself.  libstdc++ has some
> xmethods and sometimes you'll stumble across a frame filter; and there's
> at least one unwinder out there.
>
> There's some links here
>
>     https://sourceware.org/gdb/wiki/ExtensionsInPython
>
> Tom