[RTEMS Project] #3028: Run-Time Tracing

[RTEMS trac]

#3028: Run-Time Tracing
-----------------------------+------------------------
 Reporter:  Spencer Goodwin  |      Owner:  chrisj@…
     Type:  project          |     Status:  new
 Priority:  normal           |  Milestone:  Indefinite
Component:  tools            |    Version:  4.12
 Severity:  normal           |   Keywords:  SoC
-----------------------------+------------------------
 == CTF integration ==

 [http://www.efficios.com/ctf CTF] is really neat and brings to RTEMS a
 range of features we really need. The format is good and applicable to
 RTEMS and the post processing and real-time monitoring tools are valuable.

 The CTF has a range of tools and parts and this task is to bring those
 together and into the RTEMS Trace Linker. The goal is to encapsulate what
 is needed to use CTF and what it provides with the functionality of the
 RTEMS Trace Linker to build an application for a user that uses CTF. The
 `rtems-tld` tool knows about RTEMS and function signatures (see task 1)
 and it can be taught to internally invoke the CTF tools to create a
 required configuration files and target code to integrate with the CTF
 post processing tools. Being able to use the Capture Engine is considered
 an advantage.

 A key part is [https://github.com/efficios/barectf barectf]. This accepts
 a YAML configuration and generates suitable C code for integration into
 the application. This tool can be wrapped inside the `rtems-tld` and used
 transparently to the user. The `rtems-tld` can build any `barectf`
 generated code for a target because it already knows the compiler and
 flags required by the target. The user's code is wrapped by the GNU ld and
 that creates the dependencies to the `rtems-tld` generated code and in
 turn to the `barectf` generated code. No user code is touched at the
 source or even the object file level and this is an important requirement.

 What follow is mostly guess work on my part and needs to be clarified,
 corrected and cleaned up as we learn more. I base what is written on the
 current wrapping of trace calls is controlled by `rtems-tld` and so it can
 generate the `barectf` configuration file. The `barectf` generated code
 takes in the trace data and returns CTF format records suitable for
 buffering. The Capture Engine is used because it provides safe concurrent
 buffering of data. The project is bring all this together.

 The task can be divided up into:

 1. Investigate how `barectf` works and what code is generated.
 2. Determine how the trace wrapped calls created by `rtems-tld` integrate
 to the `barectf` trace support. I suspect this is a matter of assigning
 event ids in the `barectf` configuration file to match the `rtems-tld`
 generated ids.
 3. Create an `rtems-tld` generator to generate C code to bind to the
 `barectf` calls.
 4. Integrate the `barectf` output support to the Capture Engine so it
 performs the buffering. This assumes the `barectf` code generated is
 sequential and event processing is sequential and contains no code to
 update global variables. The concurrent activity is the buffering and this
 is handled by the Capture Engine.
 5. Determine how to add extra special features such as CPU number.

 The final part of this task is transport to the host machine. How this
 happens has not been determined yet and is open to suggestions and
 innovation.

--
Ticket URL: <http://devel.rtems.org/ticket/3028>
RTEMS Project <http://www.rtems.org/>
RTEMS Project