GDB variants accepting plugins (to the debugger) ?

GDB variants accepting plugins (to the debugger) ?

[Basile Starynkevitch]

Hello

I am using GDB-17.1 on Linux/Debian/x86-64 to debug a C++ coded, GPL licensed, inference engine


Is there any GDB variant accepting plugins to the debugger process
(these could be definitely useful to display C++ data in a nice way, std::vector or std::map instances come to mind immediately).

I do know that GDB accept eg Guile or Python scripts.
But coding manually a Python or Guile function for every important C++ classes of a software is very time consuming


I regret that GDB 17.1 has not evolved into something similar to the old and unmaintained UPS open source debugger
https://ups.sourceforge.net/ which sadly is not working on Linux/AMD-64 computers running a recent kernel 6.17 and
and using recent libc and libstdc++

Regards.
-- 

Basile STARYNKEVITCH                    basile AT starynkevitch DOT net
8 rue de la Faïencerie                       http://starynkevitch.net/Basile/  
92340 Bourg-la-Reine                         https://github.com/bstarynk
France                                https://github.com/RefPerSys/RefPerSys
                  https://orcid.org/0000-0003-0908-5250

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

[Eli Zaretskii via Gdb]

> From: Basile Starynkevitch <basile@starynkevitch.net>
> Cc: team@refpersys.org
> Date: Fri, 30 Jan 2026 14:13:51 +0100
> 
> I am using GDB-17.1 on Linux/Debian/x86-64 to debug a C++ coded, GPL licensed, inference engine
> 
> 
> Is there any GDB variant accepting plugins to the debugger process
> (these could be definitely useful to display C++ data in a nice way, std::vector or std::map instances come to mind immediately).
> 
> I do know that GDB accept eg Guile or Python scripts.
> But coding manually a Python or Guile function for every important C++ classes of a software is very time consuming

Did you read the node "Auto-loading extensions" in the GDB manual?
GDB installs such an auto-loaded extension for standard C++ classes,
which actually uses printers.py provided by GCC/libstdc++
distribution.  But you can use the same mechanism to provide
extensions for your classes, if needed.

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

[Simon Marchi via Gdb]

On 2026-01-30 08:33, Eli Zaretskii via Gdb wrote:
>> From: Basile Starynkevitch <basile@starynkevitch.net>
>> Cc: team@refpersys.org
>> Date: Fri, 30 Jan 2026 14:13:51 +0100
>>
>> I am using GDB-17.1 on Linux/Debian/x86-64 to debug a C++ coded, GPL licensed, inference engine
>>
>>
>> Is there any GDB variant accepting plugins to the debugger process
>> (these could be definitely useful to display C++ data in a nice way, std::vector or std::map instances come to mind immediately).
>>
>> I do know that GDB accept eg Guile or Python scripts.
>> But coding manually a Python or Guile function for every important C++ classes of a software is very time consuming
> 
> Did you read the node "Auto-loading extensions" in the GDB manual?
> GDB installs such an auto-loaded extension for standard C++ classes,
> which actually uses printers.py provided by GCC/libstdc++
> distribution.  But you can use the same mechanism to provide
> extensions for your classes, if needed.

Here's the file Eli is referring to, for libstdc++:

https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=libstdc%2B%2B-v3/python/libstdcxx/v6/printers.py;hb=HEAD

And here is the API it uses:

https://sourceware.org/gdb/current/onlinedocs/gdb.html/Pretty-Printing.html

Simon

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

[Basile Starynkevitch]

On Fri, 2026-01-30 at 10:35 -0500, Simon Marchi via Gdb wrote:
> 
> 
> On 2026-01-30 08:33, Eli Zaretskii via Gdb wrote:
> > > From: Basile Starynkevitch <basile@starynkevitch.net>
> > > Cc: team@refpersys.org
> > > Date: Fri, 30 Jan 2026 14:13:51 +0100
> > > 
> > > I am using GDB-17.1 on Linux/Debian/x86-64 to debug a C++ coded, GPL licensed, inference engine
> > > 
> > > 
> > > Is there any GDB variant accepting plugins to the debugger process
> > > (these could be definitely useful to display C++ data in a nice way, std::vector or std::map instances come to mind immediately).
> > > 
> > > I do know that GDB accept eg Guile or Python scripts.
> > > But coding manually a Python or Guile function for every important C++ classes of a software is very time consuming
> > 
> > Did you read the node "Auto-loading extensions" in the GDB manual?
> > GDB installs such an auto-loaded extension for standard C++ classes,
> > which actually uses printers.py provided by GCC/libstdc++
> > distribution.  But you can use the same mechanism to provide
> > extensions for your classes, if needed.
> 
> Here's the file Eli is referring to, for libstdc++:
> 
> https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=libstdc%2B%2B-v3/python/libstdcxx/v6/printers.py;hb=HEAD
> 
> And here is the API it uses:
> 
> https://sourceware.org/gdb/current/onlinedocs/gdb.html/Pretty-Printing.html
> 
> Simon

I am (perhaps incorrectly) understanding that I could inside the ELF executable embed some ELF section containing Python code for GDB.

https://sourceware.org/gdb/current/onlinedocs/gdb.html/dotdebug_005fgdb_005fscripts-section.html
mention something. I don't understand if the script file name should be an absolute path, or a relative one?

If the Python script is a relative path, is it relative the working directory of GDB or of the debugged process?

Does anyone has some concrete toy -preferably opensource- example (for an open source C++ program, on Linux, and how to link that program 
to add the ELF sections containing Python code for the GDB debugger)?

Thanks
-- 

Basile STARYNKEVITCH                    basile AT starynkevitch DOT net
8 rue de la Faïencerie                       http://starynkevitch.net/Basile/  
92340 Bourg-la-Reine                         https://github.com/bstarynk
France                                https://github.com/RefPerSys/RefPerSys
                  https://orcid.org/0000-0003-0908-5250

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

[Simon Marchi via Gdb]

On 2026-01-30 12:03, Basile Starynkevitch wrote:
> On Fri, 2026-01-30 at 10:35 -0500, Simon Marchi via Gdb wrote:
>>
>>
>> On 2026-01-30 08:33, Eli Zaretskii via Gdb wrote:
>>>> From: Basile Starynkevitch <basile@starynkevitch.net>
>>>> Cc: team@refpersys.org
>>>> Date: Fri, 30 Jan 2026 14:13:51 +0100
>>>>
>>>> I am using GDB-17.1 on Linux/Debian/x86-64 to debug a C++ coded, GPL licensed, inference engine
>>>>
>>>>
>>>> Is there any GDB variant accepting plugins to the debugger process
>>>> (these could be definitely useful to display C++ data in a nice way, std::vector or std::map instances come to mind immediately).
>>>>
>>>> I do know that GDB accept eg Guile or Python scripts.
>>>> But coding manually a Python or Guile function for every important C++ classes of a software is very time consuming
>>>
>>> Did you read the node "Auto-loading extensions" in the GDB manual?
>>> GDB installs such an auto-loaded extension for standard C++ classes,
>>> which actually uses printers.py provided by GCC/libstdc++
>>> distribution.  But you can use the same mechanism to provide
>>> extensions for your classes, if needed.
>>
>> Here's the file Eli is referring to, for libstdc++:
>>
>> https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=libstdc%2B%2B-v3/python/libstdcxx/v6/printers.py;hb=HEAD
>>
>> And here is the API it uses:
>>
>> https://sourceware.org/gdb/current/onlinedocs/gdb.html/Pretty-Printing.html
>>
>> Simon
> 
> I am (perhaps incorrectly) understanding that I could inside the ELF executable embed some ELF section containing Python code for GDB.
> 
> https://sourceware.org/gdb/current/onlinedocs/gdb.html/dotdebug_005fgdb_005fscripts-section.html
> mention something. I don't understand if the script file name should be an absolute path, or a relative one?
> 
> If the Python script is a relative path, is it relative the working directory of GDB or of the debugged process?
> 
> Does anyone has some concrete toy -preferably opensource- example (for an open source C++ program, on Linux, and how to link that program 
> to add the ELF sections containing Python code for the GDB debugger)?

Putting the scripts (either just the name, or the full contents) in a
section of the executable is one way, but you don't have to.

There are a few ways that GDB can find and auto-load the Python script
associated to a binary.  The simplest is to have a file suffixed with
`-gdb.py` right next to your binary.  So if you have binary `foo`, GDB
will attempt to load the Python script `foo-gdb.py` right next to `foo`.

If that one is not found, then GDB looks for foo-gdb.py in other places.
If you do "set debug auto-load 1" prior to loading your binary, you will
see where GDB attempts to load the scripts from.

For example, on my system, GDB will auto-load

  /usr/share/gdb/auto-load/usr/lib/libstdc++.so.6.0.34-gdb.py

whenever the libstdc++.so.6.0.34 library gets loaded.

See the doc here:

https://sourceware.org/gdb/current/onlinedocs/gdb.html/objfile_002dgdbdotext-file.html#objfile_002dgdbdotext-file

Simon

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

[Tom Tromey]

>>>>> "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.

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

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

[Matt Rice via Gdb]

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

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

[Tom Tromey]

>>>>> "Matt" == Matt Rice <ratmice@gmail.com> writes:

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

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

FWIW another idea in this space is the LLDB bytecode

https://lldb.llvm.org/resources/formatterbytecode.html

That page makes it sound like the plan is to have the compiler emit this
bytecode, but I haven't really paid attention to see if that's happened.

I wonder if it would be possible to implement any of these without
really touching the gdb core.  That is, some Python shims that load wasm
or whatever and do what is needed.

Tom

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

[Jan Vrany via Gdb]

On Sat, 2026-01-31 at 10:00 -0700, Tom Tromey wrote:
> > > > > > "Matt" == Matt Rice <ratmice@gmail.com> writes:
> 
> Matt> Anyhow I would be/have been somewhat interesting in putting in
> Matt> time/effort into working on this sort of building out wasm inspired by
> Matt> parts of the python API, but it feels like you'd probably want to put
> Matt> a big experimental sticker on it in the sense that it could end up
> Matt> with some component-model upstream change which in theory may mean
> Matt> that the bytecode compiled pretty printer may be tied to a particular
> Matt> version gdb using whatever version of the component model. In the same
> Matt> sense that we currently rely on a python version (with the difference
> Matt> being that python is much longer history of stabilization than the
> Matt> component model which)
> 
> Matt> So in my opinion there is a little more to it than just putting in the
> Matt> work, there is a lot less prior art than python modules.
> Matt> Perhaps it would be best to start out with configure option not
> Matt> enabled by default, with the understanding that it is currently
> Matt> experimental.
> Matt> something like --enable-experimental-wasm-plugins or some such.
> Matt> Anyhow I would be excited to play around with it some if there was a
> Matt> roadmap for how we want to handle these issues...
> 
> FWIW another idea in this space is the LLDB bytecode
> 
> https://lldb.llvm.org/resources/formatterbytecode.html
> 
> That page makes it sound like the plan is to have the compiler emit this
> bytecode, but I haven't really paid attention to see if that's happened.
> 
> I wonder if it would be possible to implement any of these without
> really touching the gdb core.  That is, some Python shims that load wasm
> or whatever and do what is needed.
> 
> 

I do not see why not - a Python API to access sections and/or minsymbols
might be needed though. I've done something similar in the past, including
the section/minsymbol API (but never got to polish it an submit :-(

Jan




> Tom