Adding capture support to score

[Chris Johns]

On 10/07/2014 6:09 pm, Sebastian Huber wrote:
> Hello Jennifer,
>
> I am about to go on vacation so I can only give some short comments.
>

Have fun.

> This patch looks a bit like approach of the Timeline Tool from Edisoft:
>
> http://lists.rtems.org/pipermail/users/2007-October/017112.html
>
> I am more in favor of linker based versions like:
>
> http://www.rtems.org/wiki/index.php/RTEMS_Trace_Tool
>

+1

What is missing is the context of the work being done. It would nice for 
Jennifer to update a wiki page with the requirements of the work, ie 
what functions need to be traced, SMP support etc.

The trace tool approach documented in the wiki has 2 parts, the host 
side for generating the stubs and the target side for controlling, 
triggering and recording the events. The first part is complex and 
requires detailed analysis of the DWARF debug info to extract the 
function signature being wrapped [1]. The second part is a simpler and a 
more manageable task and I understand after a meeting with Joel and 
Jennifer this is the task being undertaken.

The patch posted does not meet the trace tool end requirements and needs 
to be changed. It is too invasive. I am playing with a bit of C code 
locally to figure out a solution. I suspect it will be close to what is 
needed for the final solution however there maybe some extra defines in 
the RTEMS code to make it work. I am aiming for a 0 code change in the 
score however as stated I think this is not possible. The critical bit 
is the symbol name change for the function being traced, ie define a define.

Another possible approach is to partially implement the host side based 
on a "known" list of function signatures. This would mean 0 changes to 
the score. This would be a nice solution.

[1] I see this task being related to the RTL code base for the host 
tools. The host rtems-ld tool has a C++ framework for working with ELF 
files and it makes sense to add libdwarf support to this framework to 
support this work.

> http://en.wikipedia.org/wiki/DTrace
>
> This is describes the Linux approach:
>
> http://lwn.net/Articles/132196/
>

I have looked at both these are like them. Porting dtrace would be nice 
and Linux have nice frontends. I have played with dtrace but I have not 
being given the resources to fully look at this. The Illumos people 
would like to see us use it.

> No matter what we use in the end, I think its important that it can be
> disabled at compile-time (like profiling, debug, etc.).
>
> Fatal errors should result in _Terminate().  You can add a single trace
> point to this function.
>

Logging the result can be done but then what. Everything has terminated 
and so there is no way we can extract the log with this event.

Chris