GSoC 2016 Interested in Tracing was Re:

Sun Mar 6 23:25:34 UTC 2016

Hi,

Please excuse the delay in responding.

Trace doco has been placed in the wiki here 
https://devel.rtems.org/wiki/Developer/Tracing. It outlines the overall 
structure of the tracing support we have. The key component is the trace 
linker. The purpose of the trace linker is to capture in a single user 
interface the complexities of tracing on an embedded real-time target. 
The focus of the work to date is to provide a frame work to do this. The 
trace buffering is a simplified but useful example of how to use the 
trace linker to actually trace code. The printk generator is an even 
simpler example.

I will update the Open Projects TraceTool page today.

For GSoC there are a few areas that can be worked on. They are:

  1) RTEMS Trace linker (rtems-tld) Symbol Signatures.
  2) Target Integration of the Capture Engine with rtems-tld
  3) CTF integration.
  4) Tracing tools improvements.

1) RTEMS Trace linker (rtems-tld) Symbol Signatures.

Update the elftools component and add libdwarf support to rtems-tools. 
Provide a C++ framework in a similar manner to the ELF framework to wrap 
libdwarf. The current use case for libdwarf is to get a function 
signature of a library symbol from the debug info and with this create a 
suitable function signature for the trace linker. Currently this is 
manually done by adding the signatures to the generator INI files. The 
manual approach is a stop gap measure and is not maintainable. This task 
requires good C++ skills.

2) Target Integration of the Capture Engine with rtems-tld

The Capture Engine is a module in RTEMS for the target that provides low 
level services for buffers, triggers and captures for the target. This 
task integrates the Capture Engine to the RTEMS Trace Linker to allow 
rtems-tld linked application to use the Capture Engine for the capture, 
buffering and transport of the trace data. The task also includes 
looking at adding other transports to the Capture Engine other than a 
command line and console output. A role of the Capture Engine is to 
provide an API users can access to allow custom transports. This is 
important with custom hardware with restricted external interfaces.

3) CTF integration

Isaac has been looking at this and I hope he considers joining GSoC 2016 
to help mentor the Trace project with me (Isaac, hint hint :)).

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 meta-data files and target code to integrate with the CTF post 
processing tools. Being able to use the Capture Engine is considered an 
advantage.

This task is not as defined as the other ones and requires some research 
and analysis following on from what Isaac has already done. Isaac has 
discussed the remote protocol and this is an important part and worth 
plenty of attention.

Isaac, please feel free to update and correctly anything I have said 
here. As I said I will update the wiki page under Open Projects so 
please add anything more you have related to CTF.

4) Tracing tools improvements

This is an opened ended task and not one to be initially focused on but 
is here for completeness. The rtems-tld uses the binutils symbol mapping 
feature in GNU ld and I have observed some interesting behaviour with 
it. It would be good to characterise this behaviour and if possible 
improve the support in GNU ld. I however feel there are limitations, eg 
tracing static C functions internally optimised by the compiler, C++ and 
templates, and more. Long term there maybe the need to add passes to gcc 
to allow even better trace control. I can see us using the gcc Python 
plug in tool [1]. For this to happen I would like to see a separate GCC 
Plug-In project started and trace support being just one part of it. 
This would allow other interesting but yet to be defined things 
requiring GCC plug-in passes to be collected in one place. A separate 
project for special gcc passes would allow auditing and controls to be 
added so those users in our community who need to know everything about 
the code running in their target can control what happens.

Chris

[1] https://fedorahosted.org/gcc-python-plugin/

On 04/03/2016 04:00, Isaac Gutekunst wrote:
> Hi Vivek,
>
> Chris is definitely the person most knowledgeable in this area.
>
>
>
>
>
> On 03/03/2016 11:45 AM, Joel Sherrill wrote:
>>
>>
>> On Thu, Mar 3, 2016 at 10:25 AM, Vivek Kukreja <vivekkukreja at outlook.com
>> <mailto:vivekkukreja at outlook.com>> wrote:
>>
>>     Hi everyone
>>
>>
>>     I am Vivek Kukreja, currently pursuing Masters from India. I'm
>>     interested in applying for GSOC this year. I am a skilled C
>>     Programmer and have strong understanding of OS concepts. I'm
>>     interested in system programming and kernel development.
>>
>>
>>     I am interested to work on topics under Tracing. I am intrigued by
>>     the topic. I think this will be a good place to start for me.
>>
>>
>> That's a good area that needs work. Chris Johns is the core person in
>> this area. He is in
>> Sydney and will likely comment once he is awake. :)
>>
>> I gave a presentation at the Flight Software Workshop in 2014 on the
>> RTEMS ecosystem.
>> Tracing was included in that presentation and Chris helped with the
>> slides. The slides are
>> here:
>>
>> http://flightsoftware.jhuapl.edu/files/2014/Presentations/Day-2/Session-3/2-RTEMSProjectEcosystem.pdf
>>
>>
>> There is a video of my presentation if you want to see it. But this
>> presentation covers the
>> background and status.
>>
>>     I have gone through Getting Started documentation and setup RTEMS on
>>     my machine. I have tried running the provided examples. I tried to
>>     run the tracing example, but am facing some problem during
>>     compilation (wrapper compilation error). I will continue looking
>>     into it, and report if I can't solve the problem on my own.
>>
>>
>> Focus first on doing the GSoC Hello World and adding yourself to the
>> list of students.
>> Then ask specific questions about those examples.
>>
>>     Please tell me about the open projects under the Tracing Tool. I
>>     request you to please give me some pointers to get started.
>>
>>
>> Chris is the person to make sure the task list is current and in
>> priority.
>>
>> But I know there is work to be done on generation of method trace
>> wrappers,
>> getting trace data off target (tcp/ip, etc), and producing Common Trace
>> Format
>> and integrating with the Linux Trace Toolkit.
>>
>> My understanding is that the Linux Trace Toolkit can also dynamically
>> interact (bidirectionally) with the target system. I don't know what that
>> entails but it is desirable. But it requires having basic integration
>> solved
>> first.
>
> I have done some work on the side trying to understand the lttng-live
> trace protocol
>
> The Linux Trace Toolkit has one component that runs on a potentially
> remote system, and captures trace information.
>
> A different system can connect to the system being traced using the
> lttng-live protocol.
>
> See
> https://github.com/lttng/lttng-tools/blob/master/doc/live-reading-protocol.txt
>
>
> It is a fairly straightforward binary protocol with a handshake, and a
> few interactions before raw CTF is sent back in a request/response manner.
>
>
> The lttng-live relay daemon is what provides this service.
>
> The code for that can be seen here:
>
> https://github.com/lttng/lttng-tools/tree/master/src/common/relayd
>
>
> I've done some work to implement the lttng-live protocol as a proof of
> concept as part of some development here.
>
> I'd be interested in providing some help to make RTEMS Trace Capture
> Engine support storing logs in CTF format, and making them available via
> lttng-live.
>
>
> Hope this helps as well,
>
> Isaac
>
>
>
>
>
>>
>> I hope that helps.
>>
>> --joel
>>
>>     Regards,
>>
>>     Vivek
>>
>>
>>
>>     _______________________________________________
>>     devel mailing list
>>     devel at rtems.org <mailto:devel at rtems.org>
>>     http://lists.rtems.org/mailman/listinfo/devel
>>
>>
>>
>>
>> _______________________________________________
>> devel mailing list
>> devel at rtems.org
>> http://lists.rtems.org/mailman/listinfo/devel
>>
> _______________________________________________
> devel mailing list
> devel at rtems.org
> http://lists.rtems.org/mailman/listinfo/devel