RTEMS User Level Tracing?

[Chris Johns]

On 12/22/15 02:38, Isaac Gutekunst wrote:
>
>
> On 12/20/2015 08:02 PM, Chris Johns wrote:
>> On 19/12/2015 6:36 AM, isaac.gutekunst wrote:
>>>
>>> We're interested in trace some application data in our RTEMS project.
>>> Here's a bunch of background and thoughts:
>>>
>>> I've read the following pages:
>>>      * https://devel.rtems.org/wiki/Developer/Tracing
>>>      * https://devel.rtems.org/wiki/Developer/Tracing/Trace_Linker
>>>
>>> I think I have an understanding of the current system as documented.
>>> Tracing user defined data types seems to be missing. I'm looking for
>>> something more like barectf. Is there any such support available, or any
>>> plans to support it? I don't want to reinvent the wheel.
>>
>> User defined data is not directly support but can be added if you add a
>> custom generator. There is not a great deal of documentation about how
>> to do this. An example generator is:
>>
>>   https://git.rtems.org/rtems-tools/tree/linkers/rtld-trace-buffer.ini
>>
> Cool. I'll take a closer look at this.
>> You could add anything specific you want. It is not a great solution but
>> tracing into data being passed by pointers is difficult.
>>
> Definitely. You quickly come to the great serialization problem, and are
> bound to reinvent the wheel a few times.

Yes and SMP makes this even more complicated. We need to ensure we have 
a low overhead solution. Work in this area has been done by Joel and 
Jennifer.

>> You would need to use the various options to get a copy of the trace
>> wrapper file and then get the generator to see the headers and various
>> data you want.
>>
>>> If there isn't support already, maybe some parts of the trace
>>> infrastructure can be reused, notably the backed for storing the data,
>>> and/or sending it out over the network. Are there plans to make the
>>> Trace Linker natively output CTF data?
>>
>> We would like to support CTF output. Getting this done would need
>> developer funding.
>
> We would like tracing for at least user defined data, and will be
> developing that functionality. If we could do so in a way that helps the
> existing RTEMS trace, we'd love to.
>
>>
>>> Perhaps barectf could be used for this purpose.
>>
>> I do not know what this. Do you have a reference?
>>
> https://github.com/efficios/barectf
>

Thanks

> It takes in a YAML file, and generates a C file with functions that
> allow tracing user defined structs. It will output those to a custom
> "backend" in serialized form. The documentation is pretty good. I've
> used in briefly in a bare metal PIC32 project with success.
>
> A potential plan of action:
> 1) Make a barectf backend for RTEMS. (This could re-use existing
> features). Probably package/make it available via RSB.

Is this just for data or does it handle instrumenting functions? I have 
not looked at barectf.

> 2) Update the trace linker to use it (I don't really know what this
> means just yet).

Are 1) and 2) has the same thing or part of the same piece of work?

The capture engine Joel and Jennifer updated supports SMP logging. Can 
this be used to do this?

My goal is to see all support integrated into the same trace framework 
so our users have a single place for trace support. The trace framework 
can have multiple parts, they just need to coexist in a single framework.

> 3) Make a mechanism/ document a standard way to integrate trace with a
> user application. I'd imagine this could involve a RSB package, although
> it's rather simple (yaml file becomes a C and H file that needs to be
> linked against a 'backend').

How does this relate to the RTEMS Trace linker and the function wrapping 
that it currently implements? Can the RTEMS Trace Linker be the "user 
interface" to bring all this together? This would then provide a single 
user interface for creating a traceable RTEMS executable.

>
> 4) For the ARM architecture, using the ITM to output data could be very
> useful. This could fit somewhere into this picture.
>

Transports should be a separate part. The capture engine should be 
creating buffers and a separate module manages the user interfacing and 
data extraction. Currently thee is just a cli. I am not across the ITM 
hardware and how you manager the user interactions.

> I would be doing most or all of the work here, unless of course anyone
> wants to help.
>
> I'm looking for ideas and suggestions. If there is some functionality of
> direction you'd like us to pursue, let me know.
>

Sorry about the delayed response, I have been away for a few weeks.

Chris