Changes between Version 128 and Version 129 of Developer/OpenProjects


Ignore:
Timestamp:
Aug 14, 2009, 3:10:04 PM (10 years ago)
Author:
Cocanlucian
Comment:

/* Run-Time Tracing */

Legend:

Unmodified
Added
Removed
Modified
  • Developer/OpenProjects

    v128 v129  
    7474
    7575
    76 '''Status:''' [wiki:ChrisJohns ChrisJohns] and [wiki:TBR/User/JoelSherrill JoelSherrill] have done initial work on adding trace points to RTEMS.
     76'''Status:''' [wiki:ChrisJohns ChrisJohns] and [wiki:TBR/User/JoelSherrill JoelSherrill] have done initial work on adding trace points to RTEMS. This is still work in progress.
    7777
    7878Instrument RTEMS so that a timeline visualization tool can be used to "place a scope" on a running RTEMS system.  This project has multiple parts.
     
    8686The requirements of the Run-Time tracing is to provide a common means audit an RTEMS application for conformance of input/output parameters and/or timing, or to debug an application. The auditing process typically uses a static configuration the user manages. The debugging process usually targets a standard set of calls such as the RTEMS Classic API and uses dynamic filtering to control what is looked at as the debugging session unfolds.
    8787
    88 Chris and Joel have done some initial work and prototyping has been done on the first four parts. Chris wrote the capture engine and this is currently part of RTEMS ([wiki:TBR/UserManual/Capture_Engine Capture Engine]). The purpose was to look at performance issues relating to filtering, triggering, and storage of events ready for transmission to a host. Together Chris and Joel believe that the bulk of the work adding trace points can be done automatically using the GNU ld "wrap capability" given a user generated list of trace points. The first stage of this task is to extract function signatures from existing libraries then match against the requested list of trace points to generate the wrap code module for the target. Extracting a signature lowers the on going maintenance of the signature as the tool will always match the library being traced. The next stage is to integrate this code module with the existing capture engine to allow filtering and triggering. The implementation needs to keep overheads as low as possible and to manage the threading issues that are present in this area of the code. A key requirement is not to change any code in the libraries being traced.
    89 
    90 In addition, we believe a simple text dump of the trace log on the host side can be derived in a highly automated manner. The code to transmit data from the RTEMS system and to receive the data on the host computer will have to be written. The design of the target transmit code needs to be flexible to allow for a wide range of possible transports. The first and most common transport will be TCP and this needs to be implemented. The target code needs to carefully consider stability issues. A tracing system such as this can generate more data than the transport can handle. The design needs to trade off an efficient protocol that minimizes the data sent against adding too much overhead compressing data. The host side to receive the data needs to be portable across all popular host operating systems. The preferred language is Python. The receive code can be a command line tool to save the data to a file or it could form part of a larger program. This code can become the glue between the target data and existing host applications designed to display trace data.
    91 
    92 Once data has been received on the host side, the next logical step is to display the timeline of events in a graphical fashion. This may include the development of a visualization tool or the integration of an existing application that performs this task.
    93 
    94 Greg Menke of NASA has used GNU plot to do a simple version of this and may have advice.
    95 
    96 The 2008 GSoC project dealt with the function signature extraction and generating trace code. There is also code to write a trace log to the file system. This file can be exported to a host machine for analysis by a number of available means such as flash cards, hard disk, NFS or some other network protocol. This year the GSoC project needs to:
    97 
    98 # Take the existing code and create a suitable patch for CVS.
    99 # Consolidate how a traceable application is created making the process as simple and transparent for the user as it can be.
    100 # Look at the addition of dynamic filtering and triggering. This is complicated by the handling of the event ids allocated to a specific trace point.
     88The current status of this project can be found [wiki:RTEMS_Trace_Tool_  here].
    10189= Implement POSIX Asynchronous and List IO =
    10290