From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id YaVgF3irgGnuUSQAWB0awg (envelope-from ) for ; Mon, 02 Feb 2026 08:49:44 -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=g9ZJvcx8; dkim-atps=neutral Received: by simark.ca (Postfix, from userid 112) id 520C51E08D; Mon, 02 Feb 2026 08:49:44 -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 AB47C1E08D for ; Mon, 02 Feb 2026 08:49:43 -0500 (EST) Received: from vm01.sourceware.org (localhost [127.0.0.1]) by sourceware.org (Postfix) with ESMTP id 13E8D4BA903E for ; Mon, 2 Feb 2026 13:49:43 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 13E8D4BA903E DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=sourceware.org; s=default; t=1770040183; bh=OoAg+yA5cYHdsvQT2iixoVRlv0OApqhUpNtx+A+L86g=; h=Date:To:Cc:Subject:In-Reply-To:References:List-Id: List-Unsubscribe:List-Archive:List-Post:List-Help:List-Subscribe: From:Reply-To:From; b=g9ZJvcx8nwZNXzxeQigPtz0EaYLoOu1jMbqjpMupjZvU8GGzkiXAjVJGvK0Te4P5O fm6kqYPOS+xyydumu16lBYQ/rR1v+HnQX2oiu1+Gs1Rd92XvV/dmfBWGvMhJtecvsj Xep7F9EeMr1uZ1+m4mkgyh1/jYn+E7c0/G04uda8= Received: from mail-244119.protonmail.ch (mail-244119.protonmail.ch [109.224.244.119]) by sourceware.org (Postfix) with ESMTPS id 6FB9A4BB5906 for ; Mon, 2 Feb 2026 13:49:07 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 6FB9A4BB5906 ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 6FB9A4BB5906 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1770040147; cv=none; b=F9Lwx7l2qnE5TvVy3JSEw9dCuFAvlmEKaD+Kz+0Ye+2femRxGZN5sokAh9NVkCnfDn2QxA12fzBBlQOKkYYBNhugfYSRQzKiQjQuJTPzgogIqovLPWCdklziZYFOIpF/VAJ1AdYSGoDkhaV+ehGQ1UtRBAUlJaMsbS1C7M2syhE= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1770040147; c=relaxed/simple; bh=OoAg+yA5cYHdsvQT2iixoVRlv0OApqhUpNtx+A+L86g=; h=DKIM-Signature:Date:To:From:Subject:Message-ID:MIME-Version; b=dIQIJ1VMsNv/L8lNTmmsfBsLIvgQso/SjANE52qURQpxS64rJVh+ITFpWsO1rYNqpVIBDEacsT+6kOxcWmzdZD9NSOjBeGyRjZ2CDIVrj5FLSGAhHgVco43+H2PFAPOOo1/CsZiskIugBd/VSO5r5HGr2xmWIMbSAwOcrT9e+bU= ARC-Authentication-Results: i=1; server2.sourceware.org DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 6FB9A4BB5906 Date: Mon, 02 Feb 2026 13:49:01 +0000 To: Tom Tromey , Matt Rice Cc: Basile Starynkevitch , gdb@sourceware.org, team@refpersys.org Subject: Re: GDB variants accepting plugins (to the debugger) ? Message-ID: <9de8b2c7cd7746b1de68ac4bfb629e33fbd38cb6.camel@vrany.io> In-Reply-To: <877bsxzpie.fsf@tromey.com> References: <06d90d0ef774cf4ffd69a675a9092afee18a3446.camel@starynkevitch.net> <87ikci97xh.fsf@tromey.com> <877bsxzpie.fsf@tromey.com> Feedback-ID: 40767693:user:proton X-Pm-Message-ID: f01883b9da2aa7a898c2acc357c274e58f75f6a6 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable 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: Jan Vrany via Gdb Reply-To: Jan Vrany Errors-To: gdb-bounces~public-inbox=simark.ca@sourceware.org Sender: "Gdb" On Sat, 2026-01-31 at 10:00 -0700, Tom Tromey wrote: > > > > > > "Matt" =3D=3D Matt Rice writes: >=20 > 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 p= ut > 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 particul= ar > Matt> version gdb using whatever version of the component model. In the s= ame > Matt> sense that we currently rely on a python version (with the differen= ce > Matt> being that python is much longer history of stabilization than the > Matt> component model which) >=20 > 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... >=20 > FWIW another idea in this space is the LLDB bytecode >=20 > https://lldb.llvm.org/resources/formatterbytecode.html >=20 > 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. >=20 > I wonder if it would be possible to implement any of these without > really touching the gdb core.=C2=A0 That is, some Python shims that load = wasm > or whatever and do what is needed. >=20 >=20 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