Re: [PATCH] Remove support for the Common Trace Format (CTF)

[Simon Marchi <simon.marchi@polymtl.ca>]

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 <sergiodj@sergiodj.net>
> 
> 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