CTF: University project

[Dominik Taborsky]

On Mon, 01 Dec 2014 01:26:46 +0100, Chris Johns <chrisj at rtems.org> wrote:

> On 1/12/2014 11:15 am, Dominik Taborsky wrote:
>> On Sun, 30 Nov 2014 22:26:18 +0100, Chris Johns <chrisj at rtems.org>  
>> wrote:
>>
>>> On 1/12/2014 12:17 am, Dominik Taborsky wrote:
>>>> On Sun, 30 Nov 2014 01:27:06 +0100, Chris Johns <chrisj at rtems.org>
>>>> wrote:
>>
>> ...
>>
>>>>>
>>>>> One area that has plenty of work that needs doing plus ways to
>>>>> innovate is trace. Jennifer is adding trace support to the capture
>>>>> engine [1] for SMP and I have written a trace linker [2] that has
>>>>> support to trace calls using printk. We need to hook all this  
>>>>> together
>>>>> to make a workable solution for users and we are currently looking at
>>>>> the Common Trace Format (CTF) [3] to do this. Generating CTF lets us
>>>>> integrate with Babletrace and the Linux Trace Toolkit Viewer (LTTV).
>>>>>
>>>>> The trace support we are adding attempts to solve some tough user
>>>>> requirements from the space community such as instrumenting and
>>>>> tracing software at the object level rather than instrumenting at the
>>>>> source level. This means you take software that is compiled and
>>>>> production ready and link in trace support. The support needs to be
>>>>> efficient because it is a target side software only trace.
>>>>> Transporting data off target needs to be generic and flexible because
>>>>> we have so many different target types with differing hardware.
>>>>>
>>>>> The work involves adding suitable support to the capture engine to
>>>>> extract the trace data and convert it to the CTF format. This may be
>>>>> on target or off target depending on the load it places on the  
>>>>> target.
>>>>> We have lots of pieces of code in place but the code is new and green
>>>>> so you would need to work across all parts. We need support for
>>>>> generating trigger and trace control maps and this may be linked to
>>>>> the CTF format and Babeltrace. There will be work at real-time  
>>>>> capture
>>>>> level, the trace linking parts on the host, and CTF integrations.
>>>>>
>>>>> Joel and I met three of the EfficiOS people at GSoC this year and
>>>>> discussed this work so we would work with them.
>>>>>
>>>>
>>>> So you're working on the capture engine itself,
>>>
>>> I am not but Jennifer is. I am not sure what remaining work she has
>>> planned. I have been doing little bits with the trace linker and that
>>> code needs work to integrate with the capture engine. For example
>>> trigger maps plus other controls.
>>>
>>>> while my job would be to compile the trace captured into a CTF,
>>>
>>> If you are lucky this might be the case. How we integrate to that code
>>> base has not been looked at. Using this format lets us use the nice
>>> front end tools that exist. Any changes will require us working with
>>> theupstream project.
>>
>> I'm not planning to change it, after my blitz look at it, it seems very
>> comprehensive.
>>
>>>
>>>> possibly transmitting it over to some other machine and decompiling
>>>> it again?
>>>
>>> Yes these tasks exist. The transmission task is complex because of the
>>> possible overhead it can create. As Joel said we need to create
>>> trigger maps and merge them into the system some how plus there are
>>> possible stability issues where the trace overloads the target to be
>>> considered.
>>
>> These are implementation details, right now I worry about design, i.e.
>> what am I supposed to do... :)
>>
>>>
>>> The capture engine has 2 parts, the capture part and a command line
>>> interface via the RTEMS shell. This work relates to just the capture
>>> engine code and not the CLI.
>>>
>>>>
>>>> To make sure, this means implementing some kind of state automata on
>>>> both ends, right?
>>>>
>>>
>>> I am not sure this process is that exact.
>>
>> It seems to me like that, but let's skip that for now.
>>
>>
>> Right now I worry about my goals. I need to give my teacher some kind of
>> roadmap what I'll be doing. After that I'll dive into the code.
>
> I understand and this make sense.
>
>>
>> I need a milestone to achieve during February and then possibly another
>> during June. Can you select one milestone for February using an educated
>> guess what could be achieved, perhaps only as alpha version? I just need
>> something to aim at.
>
> Yes I think we can do this.
>
>>
>> Thanks for your patience with me, Chris! :)
>>
>
> No need to thank me, it is us who should thank you for taking an  
> interest.
>
> Let me think about the specifics. I will look into babletrace some more  
> to see how we would interface. I am happy to take the specifics of a  
> timeline for you off line with Gedare and Joel. How does that sound ?

You mean you want to discuss the specifics in person with Gedare and Joel?  
I'm not sure I understand. But if so, I agree.

>
> Chris