I made a tool to convert FreeRTOS trace recorder traces to CTF, primarily to take advantage
of the existing LTTng kernel analyses in trace compass for a personal project.
It’s still very much in the prototype stage, and there are lots of improvements to be made, but it does work.
Figure I would share in case anyone finds it useful.
6 Likes
Thank you for sharing your project!
1 Like
Hey there,
That was super impressive!!. Thank you for sharing the link. Your tool to convert FreeRTOS trace-recorder traces to CTF format seems like a valuable addition for anyone working with FreeRTOS. Leveraging existing LTTng kernel analyses in Trace Compass can provide valuable insights for debugging and optimization. Even though it’s in the prototype stage, your initiative to share it on GitHub is commendable. I’m sure it will be greatly appreciated by the FreeRTOS community.
3 Likes
Thanks @bitsnstuff for sharing the project.
Very Cool!
I have been working on a similar project and initially explored using barectf + babbletrace + TraceCompass as well.
In the end I went a different approach because of the following problems:
- I wasn’t sure if it was possible to safely use barectf from an ISR context (shared data buffer is not volatile?)
- As far as I could tell there is no cross-platform distribution for babletrace2? Only linux and complile-on-your own? I need this for a class setting, so a plug-and-play setup is rather important
- I did not find any documentation about the linux LTTng trace format that I understand builds on top of CTF? How do CTF messages need to be formatted for Tracecompass to pick them up correctly?
If you have pointers/thoughts on the above I would be very interested to hear - especially documentation for the LTTng stuff
In the end I opted for a simple custom varint-style encoding scheme with COBS framing and a simple python script that generates the C enoder and rust decoder.
As a viewer I am using google’s perfetto because having it run in the browser saves me from having to get software installed on 300+ student laptops
Right now I am working on porting my initial python draft to rust, but my ultimate target is to have the varint/cobs decoder and translater compiled to WASM running in a static website that then converts to the perfertto proto format and simply redirects there.
A quick screenshot from an early prototype:
Very cool project! Thank you for sharing!
1 Like
Why did this get flagged and hidden? I received this in a forum summary email and thought it was interesting, so I clicked the link. Only to find out the message has been hidden.
When did you find that to be the case? I presume it’s showing for you now?
There have been a lot of fake accounts and spam activity recently, causing us to turn automatic spam detection and filtering sensitivity up, and it’s possible this post was incorrectly flagged. It is also possible the post went into a moderation queue when it was first posted, which happens occasionally, but shouldn’t have been hidden again once it was originally approved.
I have unhide the post and it should now be normally visible.
Thanks for the quick response guys. I can see it again now.
I’m sorry to hear people are creating fake accounts and are sending spam messages. Wasting people’s time that could be spend on making FreeRTOS even better.
Thanks @schilkp!
I can definitely see why you took that approach, it makes a lot of sense given your environment. Your prototype looks very promising, do you plan on making it open source?
I’m not aware of any real LTTng trace format documentation either. Ultimately I ended up
cross referencing the kernel source with the trace compass plugins to figure out what the
schema should look like (trace metadata environment key/values, event and field classes, etc).
Since I’m just targeting the kernel analysis plugins, this was limited to only a handful of scheduling and IRQ events that map well enough to what trace recorder logs.
It may be possible to leverage some of the other analyses as well by mapping more of the kernel objects and their state (i.e. task blocked on a queue) but I haven’t done enough source diving to see how feasible it is.
I also briefly explored making a set of FreeRTOS specific plugins for trace compass, but that didn’t progress much (didn’t want to spend my time learning java ).
I’ve worked with barectf in the past a bit (auxoncorp/barectf-platform-pktring on github) and I think it should be possible to make a trace backend with it. It’s been a while, but IIRC it didn’t have a mechanism to supply stream packet context fields, which the LTTng plugins appear to rely on for CPU identification.
Hi!
Thanks for your insights! Cool to see you “reverse engineered” the LTTng stuff - I thought about having a look at the source but in the end did not bother 
In the meantime I have a minimal working prototype of my tracer up. See this post:
Sorry for the delayed reply and all the best,
Philipp
2 Likes