Considering removing CTF (Common Trace Format) support in GDB

Considering removing CTF (Common Trace Format) support in GDB

[Simon Marchi]

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

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

[Luis Machado]

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?

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

[Tom Tromey]

>>>>> "Simon" == Simon Marchi via Gdb <gdb@sourceware.org> writes:

Simon> My personal opinion is (disclaimer: I work for EfficiOS, the company behind the
Simon> Babeltrace project): as much as I would like to see Babeltrace 2 being used
Simon> more, I don't think the CTF support in GDB, as it is today, makes sense.

...

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

Sounds reasonable to me.

Tom