Hi Chris,<br><br>I am also interested to apply GSoc with run-time tracing. Your explanation below helps a lot! <br><br>My understanding and questions for this project is as following, Your comments to confirm it or any correction would be greatly appreciated.<br>
<ul><li> Addition of trace points to generate log entries</li><ul><li>Currently the Capture engine only hooks RTEMS user extension and trace those events including Task creation, Task initiation, Task reinitiation, Task deletion, Task context switch, Post task context switch, Task begin, Task exits, Fatal error detection, which is defined by <br>
typedef struct {<br> /** This field is the thread creation handler. */<br> User_extensions_thread_create_extension thread_create;<br> /** This field is the thread starting handler. */<br> User_extensions_thread_start_extension thread_start;<br>
/** This field is the thread restarting handler. */<br> User_extensions_thread_restart_extension thread_restart;<br> /** This field is the thread deleting handler */<br> User_extensions_thread_delete_extension thread_delete;<br>
/** This field is thread context switch handler. */<br> User_extensions_thread_switch_extension thread_switch;<br> /** This field is the thread beginning handler. */<br> User_extensions_thread_begin_extension thread_begin;<br>
/** This field is thread exiting handler. */<br> User_extensions_thread_exitted_extension thread_exitted;<br> /** This field is the fatal error extension. */<br> User_extensions_fatal_extension fatal;<br>
} User_extensions_Table;</li><li>Current capture engine hook the user extension table as prototype to test performance impact by introducing the filtering, triggering, and storage of events. So this part of project is to add tracing points by using "Wrap capability" of GNU ld.</li>
<li>For first stage, there are two lists, one is the function list specified by user, another is the function list extracted from the library. The task is, for every function matched, generated __Wrap version.</li><li>For second stage, integrate the new __Wrap functions with the existing capture engine to enable filtering and triggering.</li>
<li>This way could make it possible to add a bulk of tracing point without changing any code in the libraries to be traced.<br></li></ul><li> Transmission of logged data to host</li><ul><li>The first challenge of this part is to make the system and the log survive from high traffic.</li>
<li>The second challenge is to implement it in TCP while providing the flexibility for other transports in future.</li><li>The third challenge is to trade off minimizing the data to be sent across the network against the over-head to compress data.<br>
</li></ul><li> Receipt of logged data on host</li><ul><li>Use Python to write a CLI to receive data into a file.<br></li></ul><li> Decoding of logged data on host</li><ul><li>From the compressed data received, decode it for high-level application to display as tracing data.<br>
</li></ul><li> GUI Timeline Visualization tool</li><ul><li>Use GNUplot to integrate the decoded data into visualization format. What kind of visualization is expected?</li></ul></ul>Regarding to the schedule, I have no idea how long it need to figure out the set of user generated list of trace points.<br>
<br><br>Thanks,<br>Alan<br><br>
<hr>
<ul><li><em>Date</em>: Wed, 19 Mar 2008 12:24:09 +1100</li><li><em>From</em>: chrisj at <a href="http://rtems.org">rtems.org</a> (Chris Johns)</li><li><em>Subject</em>: student for gsoc2008</li></ul>
<hr>
<pre>Maria Soler wrote:<br>> Hi,<br>> <br>>> Just start discussing it on the list. That way the entire<br>>> community can provide answers and we can enhance the<br>>> ideas page to answer questions. Even if you are<br>
>> trying to decide between multiple ideas, it will capture<br>>> information for when the others get tackled.<br>>><br>>> I definitely want to help everyone on their project proposal.<br>>><br>
> <br>> The project that catches more my attention is the run-time tracing. It<br>> is said that some prototype is already in the code. I've been taking a<br>> look at the code.. but it is difficult to follow it at the first look.<br>
> Can you point out any specific parts to look at for understanding?<br>> <br><br>The Wiki page in Open Projects talks about multiple parts. The prototype code<br>refers to 2 specific parts. The first is the Capture Engine in the RTEMS<br>
source tree. This code is under cpukit/libmisc/capture. I have a tutorial on<br>how to use the Capture engine with the pc BSP and qemu. This can be found in<br>my ftp area:<br><br> <a rel="nofollow" href="ftp://www.rtems.org/pub/rtems/people/chrisj/capture">ftp://www.rtems.org/pub/rtems/people/chrisj/capture</a><br>
<br>The Capture engine code currently only hooks the RTEMS user extensions and<br>traces those events. This API is documented in the C User Manual. The<br>interface allowed easy access to a readily available stream of events from<br>
RTEMS without extensive RTEMS changes as the focus of the work was on<br>filtering and triggering in timely manner.<br><br>The capture code has 2 parts. The capture engine (capture.[ch]) and a command<br>line user interface (capture-cli.[ch]). An application wishing to use the<br>
capture engine via the CLI calls 'rtems_capture_cli_init'. The separation<br>allows for the addition of other interfaces such as TCP. How well this<br>separation is currently implemented will only be determined when something<br>
like TCP is added. I am sure some refactoring will be needed.<br><br>The capture engine code has a few parts. The first is a collection of utility<br>type functions such as 'rtems_capture_match_names' and<br>'rtems_capture_match_ids'. Then some useful functions such as<br>
'rtems_capture_create_control', 'rtems_capture_create_capture_task' and<br>'rtems_capture_record'. The last one handles the filtering and the placing of<br>the record in the event buffer. The other important function in this group is<br>
the 'rtems_capture_trigger' function. This handles the triggering. This code<br>requires an understanding of how the various trigger types are mapped to the<br>capture control structure. Understanding the terms is important as well as the<br>
the correct perspective. For example a "from trigger" on the task being<br>"switched to" requires you look at the "to" task's "from" list for the "from"<br>task. A "to" trigger on a "from" task is the opposite. Yeap it does get a<br>
little twisted and takes a little time to understand so do not rush this part.<br>The tutorial helps here as it shows the type of triggers at a high level. The<br>next group of functions pick up the events from the context switch user<br>
extension. The final group is the API to the capture engine to control and<br>configure it. The difficult one here is the 'rtems_capture_set_trigger'<br>function again because of the how you look and name triggers.<br>
<br>The second part of the prototype code relates to how Joel and I see RTEMS<br>feeding events to the Capture engine. Joel found the linker had a --wrap<br>option and this is a really nice feature of the GNU linker. The man page for<br>
ld has the details. It allows you to write a function called __wrap_malloc and<br>in it call __real_malloc. If you then pass to the linker the option '--wrap<br>malloc' and the linker will point all 'malloc' calls to __wrap_malloc and pull<br>
in malloc from the C library and rename it __real_malloc. No code changes in<br>the library and no code is recompiled with special defines. The prototype code<br>I have takes a library or object file and attempts to extract the function<br>
signatures from that library. Joel has code that takes function signatures and<br>creates the wrap code that is linked to the application. This means we take a<br>user created a list of functions we wish to trace and the first tool obtains<br>
the function signatures from the library, the second tool creates a C file of<br>wrapped functions and final phase is to relink the application.<br><br>The final piece of the puzzle is to integrate this into the existing capture<br>
engine. The interesting issues to resolve are the management of the filters<br>and triggers as there could be a large number and event number allocation and<br>tracking for each entry and exit of the traced function. A further issue to<br>
consider is the capture of arguments and return values.<br><br>I hope this helps.<br><br><br>Regards<br>Chris<br><br><br></pre><br>