[gst-embedded] tool+patches for lower overhead gstreamer tracing

Rob Clark rob at ti.com
Tue Jul 21 19:06:22 PDT 2009


btw, some of you working on gstreamer on embedded platforms might be  
interested in this:

I have been given permission by my employer to release an in-house  
tracing tool that I had developed in the past for "printf()" style  
traces from embedded systems:

    <http://plato.googlecode.com/>

This currently supports ARM processors running linux (although the ARM  
specific parts are relatively minimal if someone has interest in  
porting to other platforms).  There are patches for gstreamer (and TI  
openmax) here:

    <http://code.google.com/p/plato/wiki/GstreamerIntegration>

This provides a replacement for printf() that is build as a shared  
library and linked into the gstreamer (or whatever) application.   
Compared to the default printf() traces, it has a few optimizations:

   1) only the program-counter + format string ptr + arguments are  
sent to the PC.. the overhead of doing the sprintf() sort of string  
formatting operation is done on the host PC.
   2) since the program-counter (or actually link-register) is sent to  
the PC, we can omit the function name, file name, and line number.
   3) the trace data (and timestamp) are simply written into a  
circular buffer from the thread generating the trace.  If you overload  
the connection to the PC (for example, ethernet), traces will be  
dropped (this is indicated in the PC tool), so the impact to real-time  
behavior of the program is minimal.

On the host PC, you configure PLATO with the path to the location of  
the root filesystem.  PLATO reads the executable and shared libraries  
to extract the .text sections (format string), symbol table (function  
names), as well as debug info if present (file and line # tables)

The end result is that I can run pipelines, such as movie playback at  
30fps, with more or less all traces enabled, and not drop frames or  
have gaps in audio.  With the default printf() traces, I cannot enable  
too many traces before significant number of buffers are getting  
dropped.

This has been pretty helpful to me for debugging various timing  
related issues, which had a tendency to disappear before when I  
started enabling traces.

I hope this is useful to others.  The PC side part should be pretty  
portable to other platforms (at least using ELF executable/library  
files), and the target side part has just a little bit of ARM  
assembly... (there is actually already some minimal PPC support too.)   
If someone is interested to use this on other platforms, feel free to  
ping me and I'll try to point you in the right direction.



BR,
-R





More information about the Gstreamer-embedded mailing list