Mirror of the gdb mailing list
 help / color / mirror / Atom feed
From: Simon Marchi via Gdb <gdb@sourceware.org>
To: Basile Starynkevitch <basile@starynkevitch.net>,
	Eli Zaretskii <eliz@gnu.org>
Cc: gdb@sourceware.org, team@refpersys.org
Subject: Re: GDB variants accepting plugins (to the debugger) ?
Date: Fri, 30 Jan 2026 12:16:29 -0500	[thread overview]
Message-ID: <09d20ae3-4bdd-4e75-a57c-df5676eeaea8@simark.ca> (raw)
In-Reply-To: <e866a1d29cdf30c67aa83f67533f33129af2ce26.camel@starynkevitch.net>



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

  reply	other threads:[~2026-01-30 17:17 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-01-30 13:13 Basile Starynkevitch
2026-01-30 13:33 ` Eli Zaretskii via Gdb
2026-01-30 15:35   ` Simon Marchi via Gdb
2026-01-30 17:03     ` Basile Starynkevitch
2026-01-30 17:16       ` Simon Marchi via Gdb [this message]
2026-01-30 20:12 ` Tom Tromey
2026-01-31  2:36   ` Matt Rice via Gdb
2026-01-31 17:00     ` Tom Tromey
2026-02-02 13:49       ` Jan Vrany via Gdb

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=09d20ae3-4bdd-4e75-a57c-df5676eeaea8@simark.ca \
    --to=gdb@sourceware.org \
    --cc=basile@starynkevitch.net \
    --cc=eliz@gnu.org \
    --cc=simark@simark.ca \
    --cc=team@refpersys.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox