[lttng-dev] CTF semantics

Mathieu Desnoyers mathieu.desnoyers at efficios.com
Tue Jun 14 16:10:46 UTC 2016


----- On Jun 14, 2016, at 7:09 AM, Milian Wolff milian.wolff at kdab.com wrote:

> Hey all,
> 
> I have looked through the CTF specification and ponder using it to replace my
> custom text-based output format of heaptrack.

Very cool!

> 
> At this stage, I have a fundamental question: How do the existing viewers like
> Trace Compass understand the semantics of the data? Or are the viewers not
> generic but instead rely on the existing generators like lttng? How does one
> know e.g. what the backtrace of a given event is?

CTF only specifies the data layout and associates events/fields to names
(namespacing). The analyses associate meaning to the information gathered
by using the namespace associated to the tracer that collected the trace,
event and field names.

For a lttng backtrace (we have a ongoing work prototype branch here which
requires frame pointers for user-space applications:
https://github.com/compudj/lttng-modules-dev/commits/callstack), we can
associate the callstack_user context name to this callstack concept, and
if the trace viewer wants to really show this as a callstack (linked with
debug information to find the function names for instance), it needs to
know the semantic of this new context field for LTTng.

With the upcoming CTF 2.0, we plan on adding much more flexibility to the
spec, so we could declare user attributes that would "flag" a specific aspect
of the semantic, across various tracers. But we intend to leave the tracers
express their own semantic as much as possible, and then eventually agree
on common sets of constructs that are found in many implementations, perhaps
to create a side-spec of "standard user attributes" in the future.

CTF 2.0 will keep the data streams as-is, and change the metadata format from
TSDL (custom grammar) to JSON.

> 
> In heaptrack's current format heavily interns data to greatly reduce the file
> size of the output data. This is crucial, and can be done with minimal
> overhead. So I'd like to do the same if and when I convert to using CTF. But
> how would e.g. know how to interpret that an integer member of a struct
> actually is an index into a list of backtraces?

Just trying to understand here. So you store a backtrace once in the trace,
associate it with a unique number, and later on, if you need to save the same
backtrace, you just use this number instead ?

Thanks,

Mathieu

> 
> Thanks
> --
> Milian Wolff | milian.wolff at kdab.com | Software Engineer
> KDAB (Deutschland) GmbH&Co KG, a KDAB Group company
> Tel: +49-30-521325470
> KDAB - The Qt Experts
> _______________________________________________
> lttng-dev mailing list
> lttng-dev at lists.lttng.org
> https://lists.lttng.org/cgi-bin/mailman/listinfo/lttng-dev

-- 
Mathieu Desnoyers
EfficiOS Inc.
http://www.efficios.com


More information about the lttng-dev mailing list