From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from simark.ca by simark.ca with LMTP id 1uZqLz0wAWpRCi4AWB0awg (envelope-from ) for ; Sun, 10 May 2026 21:26:21 -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=OPRgbaob; dkim-atps=neutral Received: by simark.ca (Postfix, from userid 112) id AC9531E0C3; Sun, 10 May 2026 21:26:21 -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_MSPIKE_H2,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 ED7AC1E067 for ; Sun, 10 May 2026 21:26:17 -0400 (EDT) Received: from vm01.sourceware.org (localhost [IPv6:::1]) by sourceware.org (Postfix) with ESMTP id 550104BA23F5 for ; Mon, 11 May 2026 01:26:17 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 550104BA23F5 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=OPRgbaob Received: from smtp.polymtl.ca (smtp.polymtl.ca [132.207.4.11]) by sourceware.org (Postfix) with ESMTPS id 06C364BA23D0 for ; Mon, 11 May 2026 01:25:48 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 06C364BA23D0 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 06C364BA23D0 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=1778462749; cv=none; b=PHxmr3bhQiMBqm6L+H76Yf8sMx966R8BQ+GSwvQNRAofufV+XJpiOhHn4nI8Uw30EV+PRFb75bV55y6gprq3nrFqooyyEGKw3AwUNq6EZJ9PhEWQ43zUYeWVd2hbVRDULVPix/TM0FToR0PevJQ415dSQIvEwV9zIQIl2hnmGu4= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1778462749; c=relaxed/simple; bh=dG7cIlviWp3Upd9z97GE3b6NhuyEhfuqf6xti0504gg=; h=DKIM-Signature:Message-ID:Date:MIME-Version:Subject:To:From; b=Oyy4uv9qhCbraI1tVOHnClR9UyyhAsWd4WFn54u04JcSF7e59lnnfw4ZpH88ytdkm0+9MOuDLeDGyuI0jg9JDWI4gKHdRTlBcqRIDzVUML3VX0US4RdzfqVDf4zHIeyrNSbaX7kBGRbUYne9Rn51YpZQmdWFjo+N7T/gbRpjrik= 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=OPRgbaob DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 06C364BA23D0 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 64B1PRd7091823 (version=TLSv1/SSLv3 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Sun, 10 May 2026 21:25:32 -0400 DKIM-Filter: OpenDKIM Filter v2.11.0 smtp.polymtl.ca 64B1PRd7091823 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=polymtl.ca; s=oct2025; t=1778462733; bh=6w+ej8bx/4U9bXOLsKcCH4Flqkqa4jv+NdtZBgZL7Xw=; h=Date:Subject:To:Cc:From:In-Reply-To:From; b=OPRgbaobs4qwAcp3ZyOZuRwGnaXXLcu72sUaRWXJ/EWPnW0TBESNwGpAjUCmwT+hX UCjSvlgcRjAPoZJeDZSAcMcbCNC4XZGsJmgNv+RIL5dRSA6bDS506XcvPoqEn+gSFv yvC6m1GmMvl4Y0kD1EXrgRgM/FM6Z91m0ZByQQr0E85ZBDAXg1OxVAQ7uNRr9aWyR3 Nfx+2aoX0MKrpCtSnIDY9SRq+SqDvFohyWCyYfvFvdEY3cTOgYZ9L4XRvx/JfdF7jb UsHFr8aZs5K7y/niReBJhc09xz7eXKbrUR0X7dsV3tgTDZj36ZA5Wxb/3zzQMokUKN cTWWHkXnMSFJw== Received: by simark.ca (Postfix) id AC2D31E067; Sun, 10 May 2026 21:25:26 -0400 (EDT) Message-ID: <30dde5a1-3402-479a-824b-10768006ea7d@polymtl.ca> Date: Sun, 10 May 2026 21:25:25 -0400 MIME-Version: 1.0 User-Agent: Mozilla Thunderbird Subject: Re: [PATCH] Remove support for the Common Trace Format (CTF) To: Sergio Durigan Junior Cc: GDB Patches , doko@debian.org, Michael Jeanson References: <20260510022813.2221582-1-sergiodj@sergiodj.net> <5a1ac1cf-9c04-4576-ae05-e16c5f0a4744@polymtl.ca> <87fr3zz052.fsf@sergiodj.net> Content-Language: en-US From: Simon Marchi In-Reply-To: <87fr3zz052.fsf@sergiodj.net> Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit X-Poly-FromMTA: (simark.ca [158.69.221.121]) at Mon, 11 May 2026 01:25:27 +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 2026-05-10 12:42, Sergio Durigan Junior wrote: > On Sunday, 10 May 2026, Simon Marchi wrote: > >> On 5/9/26 10:28 PM, Sergio Durigan Junior wrote: >>> Hi there, >> >> Hi Sergio! > > Hey Simon :-). > >>> 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 :). > > Yeah, I know the feeling! > >> 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. > > Ah, got it. I can remove the Signed-off-by, no problem. > >> The patch doesn't contain the generated files (configure & al), please >> submit a patch with the generated files. > > Hm, I was following the instructions from > . > Are they out-of-date? I'm happy to update the wiki if that's the case. Weird, in all my time contributing to GDB we always sent the generated files, unless the resulting patch was too big to send on the list. > >>> 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. > > Ah, true. In fact, I believe the entire @itemx becomes unnecessary, so > I've removed it altogether. > >>> 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. > > Oh, sorry, that was a mistake indeed. Let me reintroduce the applicable > parts. > > Here's the updated patch, including the auto-generated files. Thanks, LGTM. Approved-By: Simon Marchi (add this trailer to your patch and push) Simon