From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id Ew3dMLl9AGpfHi0AWB0awg (envelope-from ) for ; Sun, 10 May 2026 08:44:41 -0400 Authentication-Results: simark.ca; dkim=pass (2048-bit key; unprotected) header.d=polymtl.ca header.i=@polymtl.ca header.a=rsa-sha256 header.s=oct2025 header.b=hCEAeHpL; dkim-atps=neutral Received: by simark.ca (Postfix, from userid 112) id B4A111E093; Sun, 10 May 2026 08:44:41 -0400 (EDT) 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 B808D1E093 for ; Sun, 10 May 2026 08:44:40 -0400 (EDT) Received: from vm01.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 6E19D4BA23DC for ; Sun, 10 May 2026 12:44:39 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 6E19D4BA23DC Authentication-Results: sourceware.org; dkim=pass (2048-bit key, unprotected) header.d=polymtl.ca header.i=@polymtl.ca header.a=rsa-sha256 header.s=oct2025 header.b=hCEAeHpL Received: from smtp.polymtl.ca (smtp.polymtl.ca [132.207.4.11]) by sourceware.org (Postfix) with ESMTPS id EDE144BA2E30 for ; Sun, 10 May 2026 12:44:11 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org EDE144BA2E30 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=polymtl.ca Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=polymtl.ca ARC-Filter: OpenARC Filter v1.0.0 sourceware.org EDE144BA2E30 Authentication-Results: sourceware.org; arc=none smtp.remote-ip=132.207.4.11 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1778417052; cv=none; b=lA6hJcndqexJqF64hDVvTy3wPNTgSpJnfeD8XazVxbufpkk92UQModK8Q75RtCtgcCdm74JQbPHrvLhCRLlVgN5fQfmSx2R/VS0Vfp4loJXyLOqtZutxqmBfm6r3wb7Br+zw6eFgYG2px+TTnK4/Xj4K34/SGsm1H6b6RsvYdV8= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1778417052; c=relaxed/simple; bh=+sa4qht7BipHUjvfjAu+V6eBUE21s4GEqobSBwdc8As=; h=DKIM-Signature:Message-ID:Date:MIME-Version:Subject:To:From; b=GdrNfkGFAPgJJrIP7yaVYLgRDYIhAwJlb3jBGkGsIyC748B4rqotlaLvIx/kVF0GuNcsD5fpDJNJCvivRY6V903WtToPCC8M3D39C9TJyictKOEZ6hHTmlS10z1f4k+3TTplwr4gixno1WIjtf9vZdkWeVJ08nk+jGnvO1P8WAQ= ARC-Authentication-Results: i=1; sourceware.org; dkim=pass (2048-bit key, unprotected) header.d=polymtl.ca header.i=@polymtl.ca header.a=rsa-sha256 header.s=oct2025 header.b=hCEAeHpL DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org EDE144BA2E30 Received: from simark.ca (simark.ca [158.69.221.121]) (authenticated bits=0) by smtp.polymtl.ca (8.14.7/8.14.7) with ESMTP id 64AChsQ9186350 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sun, 10 May 2026 08:43:59 -0400 DKIM-Filter: OpenDKIM Filter v2.11.0 smtp.polymtl.ca 64AChsQ9186350 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=polymtl.ca; s=oct2025; t=1778417040; bh=hQkfMTVgilTJob8FhEgyGs/PT4LtyZGDzo1H3tnHi1E=; h=Date:Subject:To:Cc:From:In-Reply-To:From; b=hCEAeHpLni1iWeku0C+1M/7jv0wJWB+8De+dQiUs8cfaqpM2ysnwr4JCeWXboTpf3 GIk66qx9xu/MXy/Enahy0kbaHWHZ4tH9mTAmtEOzPnvlcok7ylaViZ4GoIju5YfLdi ppoXqx4+K14u4+C2FUkyYi9W12lr8ATu4KTLXL9OnXUNjxQvLhkdobr0Kyiuwlc5XE ZokF7UG8UJspq7Hi/6MIe2Skih/753qGVeaPKNnu8sLBXXqLL6Qwn0oUWsM1UIGo25 wSSciC6TDTEL6/tbVp5HpfcF7bZlqW5w/JAmCdlB2XR/Y9IzTNiODedS/kLNwc1+FS 8LIU3m7a4lj+g== Received: by simark.ca (Postfix) id 45F441E093; Sun, 10 May 2026 08:43:54 -0400 (EDT) Message-ID: <5a1ac1cf-9c04-4576-ae05-e16c5f0a4744@polymtl.ca> Date: Sun, 10 May 2026 08:43:53 -0400 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] Remove support for the Common Trace Format (CTF) To: Sergio Durigan Junior , GDB Patches Cc: doko@debian.org, Michael Jeanson References: <20260510022813.2221582-1-sergiodj@sergiodj.net> Content-Language: fr From: Simon Marchi In-Reply-To: <20260510022813.2221582-1-sergiodj@sergiodj.net> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Poly-FromMTA: (simark.ca [158.69.221.121]) at Sun, 10 May 2026 12:43:54 +0000 X-BeenThere: gdb-patches@sourceware.org X-Mailman-Version: 2.1.30 Precedence: list List-Id: Gdb-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: gdb-patches-bounces~public-inbox=simark.ca@sourceware.org On 5/9/26 10:28 PM, Sergio Durigan Junior wrote: > Hi there, Hi Sergio! > The Debian maintainer of babeltrace (Michael, in CC) is working > towards removing the version 1 package from the archive in favour of > version 2. This makes sense as version 1 is unsupported and projects > should move to version 2. > > While digging through the archives I found PR buid/27142 (from > Matthias, also in Cc) which was filed 5 years ago requesting GDB to > support babeltrace v2. At the time Simon started a thread on gdb@ > suggesting that we should actually remove the support for CTF (Common > Trace Format) altogether, since it's a niche feature (CTF) within a > niche feature (tracepoints) and apparently GDB itself records CTF data > in an unconventional way that might break other tools. You can see > the thread here: > > https://inbox.sourceware.org/gdb/3fb1fbb6-836a-0e39-73a9-ef721630da88@polymtl.ca/ > > Long story short, the consensus seems to be that CTF support is ripe > to be removed, so that's what this patch does. I think I covered all > places that referred to either CTF or babeltrace; I recompiled GDB > here and things are still working as expected. I ran the tests I > touched and there are some failures, but they're unrelated to CTF and > I could reproduce them in a pristine tree as well. > > I've been a bit distant from the community so I don't know whether we > have a specific procedure to remove features from GDB. I remember > that when we removed support for an architecture, we used to deprecate > it in release N and then proceed with the removal on release N+1. Not > sure if this is applicable here, but let me know. > > Either way, I intend to disable support for babeltrace on Debian's GDB > soon. > > WDYT? > > Signed-off-by: Sergio Durigan Junior > > Bug: https://sourceware.org/bugzilla/show_bug.cgi?id=27142 Thanks for doing this, it's been in the back of my mind for 5 years :). I wonder if the blank line between your two trailers is valid, or if they should be contiguous. Also, we don't use the Signed-off-by tag, but I don't think it hurts to have it. The patch doesn't contain the generated files (configure & al), please submit a patch with the generated files. > diff --git a/gdb/doc/gdb.texinfo b/gdb/doc/gdb.texinfo > index 68e760699bc..40f381f812d 100644 > --- a/gdb/doc/gdb.texinfo > +++ b/gdb/doc/gdb.texinfo > @@ -16547,7 +16547,7 @@ of trace data, via the @code{target tfile} command. > > @kindex tsave > @item tsave [ -r ] @var{filename} > -@itemx tsave [-ctf] @var{dirname} > +@itemx tsave @var{dirname} The dirname version can be removed, as that was CTF-specific. > Save the trace data to @var{filename}. By default, this command > assumes that @var{filename} refers to the host filesystem, so if > necessary @value{GDBN} will copy raw trace data up from the target and > @@ -16556,44 +16556,6 @@ optional argument @code{-r} (``remote'') to direct the target to save > the data directly into @var{filename} in its own filesystem, which may be > more efficient if the trace buffer is very large. (Note, however, that > @code{target tfile} can only read from files accessible to the host.) > -By default, this command will save trace frame in tfile format. > -You can supply the optional argument @code{-ctf} to save data in CTF > -format. The @dfn{Common Trace Format} (CTF) is proposed as a trace format > -that can be shared by multiple debugging and tracing tools. Please go to > -@indicateurl{http://www.efficios.com/ctf} to get more information. > - > -@kindex target tfile > -@kindex tfile > -@kindex target ctf > -@kindex ctf > -@item target tfile @var{filename} > -@itemx target ctf @var{dirname} > -Use the file named @var{filename} or directory named @var{dirname} as > -a source of trace data. Commands that examine data work as they do with > -a live target, but it is not possible to run any new trace experiments. > -@code{tstatus} will report the state of the trace run at the moment > -the data was saved, as well as the current trace frame you are examining. > -Both @var{filename} and @var{dirname} must be on a filesystem accessible to > -the host. This removes the doc for "target tfile" entirely, that is too much. The rest looks fine. Simon