[lttng-dev] Status of MinGW support for babeltrace (either 1.x or 2.x)

[Jonah Graham]

On 15 August 2017 at 21:50, Philippe Proulx <eeppeliteloop at gmail.com> wrote:
> Why can't you use LTTng?
OK, now I am glad we have continued this discussion. I thought that
libbabeltrace provided the backend of LTTng?

Perhaps I am misunderstanding, and I am very grateful for your
insights. I will provide more details, hoping I can get more insight
:-). We are trying to add tracing support to our simulation models of
microprocessor systems (these range from a single processor simulating
bare metal to full SOC simulation models of Linux and many other RTOS
too). We already have in memory representations with plain text
outputs of things like active tasks on CPU and call stacks. We figured
if we create CTF files of the same format that LTTng does for various
linux kernel and UST traces, we could reuse and minimally customize
tracecompass to display them.

Tying back to the original question, the simulation models run on
windows, so we need a cross platform library.

> The disclaimer with CTF writer (part of libbabeltrace) is that it is not
> super fit for tracing purposes: its role is to help in the conversion
> from a trace written in some non-CTF format (for example, your text
> files) to CTF.
Well that sounds about right for our use. I just want to take the
integration back a step as the text files in our case are not
particularly machine readable. So, instead of formalizing the output
of our tool and then converting them to CTF we thought it best to do
that directly.

> As for barectf, the project's target is bare metal embedded systems, and
> you need to write your own barectf platform for each custom environment.
That seemed like a fallback option, but not right for us if we can do
it at runtime.


PS. I have found the Python bindings for libbabeltrace really useful
for experimenting. I am doing that with 1.5.3 until the 2.0 version
has Python enabled again.