Considering removing CTF (Common Trace Format) support in GDB

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

Hi,

GDB has support for saving tracepoint data in CTF [1].  Writing the CTF trace
is done by hand, but reading back the trace is done using Babeltrace [2]
version 1.  Babeltrace 1 is considered deprecated since the release of
Babeltrace 2, which is a complete re-write, with a complete clean/stable API
and everything.

Matthias (in CC) asked [3] if we could please migrate to Babeltrace 2, which
would be the logical thing to do.  However, I think we must first decide
whether we want to keep support for exporting tracepoint data as CTF.
Tracepoints is already a not so widely used feature of GDB, and saving as CTF
is a niche use-case within that.

My personal opinion is (disclaimer: I work for EfficiOS, the company behind the
Babeltrace project): as much as I would like to see Babeltrace 2 being used
more, I don't think the CTF support in GDB, as it is today, makes sense.  The
original reason (AFAIU) to have GDB output CTF was to make it easier to process
/ analyze traces created by GDB in other tools.  However, the particular CTF
layout emitted by GDB is... strange.

It looks like so (as decoded by `babeltrace2`):

...
frame: { tpnum = 2 }, { }
register: { tpnum = 2 }, { contents = "" }
memory: { tpnum = 2 }, { address = 0x40402C, length = 4, contents = [ [0] = 0, [1] = 0, [2] = 0, [3] = 0 ] }
memory: { tpnum = 2 }, { address = 0x7FFFFFFFDECC, length = 4, contents = [ [0] = 0, [1] = 0, [2] = 0, [3] = 0 ] }
frame: { tpnum = 2 }, { }
register: { tpnum = 2 }, { contents = "\x01" }
memory: { tpnum = 2 }, { address = 0x40402C, length = 4, contents = [ [0] = 1, [1] = 0, [2] = 0, [3] = 0 ] }
memory: { tpnum = 2 }, { address = 0x7FFFFFFFDECC, length = 4, contents = [ [0] = 1, [1] = 0, [2] = 0, [3] = 0 ] }
...

where each line is one "event".  The intent of CTF is that one "event" contains
all the data collected when crossing one tracepoint.  Here, the data collected
when crossing a tracepoint is layed out in 4 (and it could be more) events.  I
don't know of any tool other than GDB that would make sense out of this.

So if CTF support doesn't help in sharing the data with other tools, then it
just becomes an alternative format to GDB's own format for saving/loading trace
data.  And I don't think it's particularly useful to have two formats for this.

Simon

[1] https://diamon.org/ctf/
[2] https://babeltrace.org/
[3] https://sourceware.org/bugzilla/show_bug.cgi?id=27142