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
_______________________________________________
devel mailing list
devel@rtems.org
http://lists.rtems.org/mailman/listinfo/devel
