Re: Considering removing CTF (Common Trace Format) support in GDB

On 1/4/21 2:04 AM, Simon Marchi via Gdb wrote:
> 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.

I agree. If the new version covers all use cases that the old did, then 
it sound best to move to version 2 and drop version 1.

I take it this means the tracepoint machinery in GDB is still being used 
for some purpose?