RTEMS / Programs / Google Summer of Code

Go to Issues or rtems/programs/gsoc-merges

Issues Summary

27 - Run-Time Tracing

Merge Requests Summary

Issues

27 - Run-Time Tracing

Id

27

State

closed

Type

ISSUE

Author

Trac Migrate

Assignee(s)

Trac Migrate

Created

2017-05-31T12:51:04.000Z

Updated

2025-09-19T01:32:49.003Z

Milestone

5.1

Labels

gsoc, gsoc::large, old-indefinite, priority::normal, resolution::wontfix, tickettype::project, tool, version::5

Link

https://gitlab.rtems.org/rtems/programs/gsoc/-/issues/27

Merges

0

Original author: Spencer

CTF integration

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 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.

Author: Amar Takhar

2024-04-26T01:34:32.746Z

assigned to @tracmigrate

Author: Chris Johns

2017-06-01T02:45:00.000Z

Original author: Spencer

Excellent write up.

The capture engine has buffering support as well as filtering and triggering support to limit the data captured and to focus the trace to the specific area of interest. Is filtering and triggering handled by barectf and the YAML config file?

The idea for the transport is to have a function call handler struct that is registered for each transport, ie a transport API. What the struct looks like and so the needed calls is unknown and I feel will be defined more and more over time. The simplest transport is a buffer in memory that can be written to a file when the trace run has finished. It would be nice to have a transport framework even if the detail is limited to simplest case.

Author: Gedare Bloom

2022-02-03T20:16:59.000Z

Original author: Spencer

Current state of tracing needs to be found out, and then project can be scoped appropriately.

Author: Gedare Bloom

2022-02-25T18:54:49.000Z

Original author: Spencer

  • Resolution set to ~”wontfix”

  • Status changed from new to closed

This project is superseded by others such as Capture Engine and Trace Compass.

Author: Amar Takhar

2024-04-25T20:45:45.267Z

changed the description