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

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

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 <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 :).
> 
> 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
> <https://sourceware.org/gdb/wiki/DeveloperTips#Editing_configure.ac>.
> 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 <simon.marchi@efficios.com>

(add this trailer to your patch and push)

Simon