From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id CBNZD5TnfGl7MR4AWB0awg (envelope-from ) for ; Fri, 30 Jan 2026 12:17:08 -0500 Authentication-Results: simark.ca; dkim=pass (1024-bit key; secure) header.d=sourceware.org header.i=@sourceware.org header.a=rsa-sha256 header.s=default header.b=x8g/ayfM; dkim-atps=neutral Received: by simark.ca (Postfix, from userid 112) id 2EB991E08D; Fri, 30 Jan 2026 12:17:08 -0500 (EST) X-Spam-Checker-Version: SpamAssassin 4.0.1 (2024-03-25) on simark.ca X-Spam-Level: X-Spam-Status: No, score=-2.4 required=5.0 tests=ARC_SIGNED,ARC_VALID,BAYES_00, DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,MAILING_LIST_MULTI, RCVD_IN_DNSWL_MED,RCVD_IN_VALIDITY_CERTIFIED_BLOCKED, RCVD_IN_VALIDITY_RPBL_BLOCKED,RCVD_IN_VALIDITY_SAFE_BLOCKED autolearn=ham autolearn_force=no version=4.0.1 Received: from vm01.sourceware.org (vm01.sourceware.org [38.145.34.32]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange x25519 server-signature ECDSA (prime256v1) server-digest SHA256) (No client certificate requested) by simark.ca (Postfix) with ESMTPS id 56AD51E08D for ; Fri, 30 Jan 2026 12:17:07 -0500 (EST) Received: from vm01.sourceware.org (localhost [127.0.0.1]) by sourceware.org (Postfix) with ESMTP id CD25A4BA9020 for ; Fri, 30 Jan 2026 17:17:06 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org CD25A4BA9020 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1769793426; bh=/Uav+5T+Fj+2E+0KIyZiN3NaupfYqzPm67Q5OSLed/4=; h=Date:Subject:To:Cc:References:In-Reply-To:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: From:Reply-To:From; b=x8g/ayfM+dBPBTTmGkl7NC3avlJMfldGSNqHMlasOxD7+DCRXSBEavGy8jHNt2NGL a2anlwJuHy/5vy6N7w1IFkpOrn+WQ4LuJViDQ6GSMYvfp5Pc+SUYzQL1pH6n9BCuy5 s0HxKCH2Y20Fe5Sg9UjCVRHC5jZrXF66wmNp0iK8= Received: from simark.ca (simark.ca [158.69.221.121]) by sourceware.org (Postfix) with ESMTPS id 63F644BA9020 for ; Fri, 30 Jan 2026 17:16:31 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 63F644BA9020 ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 63F644BA9020 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1769793391; cv=none; b=aZVMj6todFVCSzntM5y6DwoUVC0+q6/xVsGuQLZRe4Puz5fKR1J1KUfxrIebZKwTLHdijrhPcZWXQ5TXq/soZYmUsnPSYTLCC7Gm9YDjWYsjMgzvM9CeQSDgJ2mYdu/olcPNdtGCYHtgp/wcxsl4TB7US0jgnOREAUwePnYeu4k= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1769793391; c=relaxed/simple; bh=gmZrMGgXYpEYpE38a7Tfx2E0zWeXBd9gbwQ3yHLom/E=; h=DKIM-Signature:Message-ID:Date:MIME-Version:Subject:To:From; b=X08WHvwxpr5pUeUv/4EyI0l/LvKusabsFgnKaOlNbOth4T88TWqZpITTn617ancKY1OUOVxMaaHOiaGcPhjV9hqOAQOCP9SDBysmiVlZ9e3wIe+3p6UfoiM0P12LA5bXHJGdcqGM6Kjs7wKWSiEw951GQbGH1o0ywUBAYlv1V4k= ARC-Authentication-Results: i=1; server2.sourceware.org Received: by simark.ca (Postfix) id 70A1B1E08D; Fri, 30 Jan 2026 12:16:30 -0500 (EST) Message-ID: <09d20ae3-4bdd-4e75-a57c-df5676eeaea8@simark.ca> Date: Fri, 30 Jan 2026 12:16:29 -0500 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: GDB variants accepting plugins (to the debugger) ? To: Basile Starynkevitch , Eli Zaretskii Cc: gdb@sourceware.org, team@refpersys.org References: <06d90d0ef774cf4ffd69a675a9092afee18a3446.camel@starynkevitch.net> <86ikcj8bth.fsf@gnu.org> Content-Language: en-US In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-BeenThere: gdb@sourceware.org X-Mailman-Version: 2.1.30 Precedence: list List-Id: Gdb mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , From: Simon Marchi via Gdb Reply-To: Simon Marchi Errors-To: gdb-bounces~public-inbox=simark.ca@sourceware.org Sender: "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 >>>> 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