profiling with RTEMS

[Kiran C]

Hi,
    Well to  profile ur code  u have many options..some of which I have
tried out.But others as I know exist.
    RTEMS is build in such a way that,simply switching the
RTEMS_MAKEFILE_PATH you should be able to switch
    BSP..
    Well if ur code only uses the Classical API( only this is implemenented
for UNIX BSP) of RTEMS,the try using the UNIX BSP.The unix BSP uses your
native compilers for building RTEMS.So the end out put that you get is a
host executable or lib.
In Cygwin its will a say an exe file.
Now u can use all the profiling and code coverage tools that exist for ur
host..namely goc and gprof.This can be acheived by simply adding the
neccesary compiler flags to the CFLAGS in the Makefile.
If you are doing code coverage then using gcov is an exccelent option( and
the only one I know about)
Say u want to do profiling then here is a set of options
a)Use gprof.
But its quite underermistic..I find it very weird.
Recently I came accros an excellent Profiling tool,Which is the best suited
for a MultiProccesor OS like RTEMS.
Its Tuning and Analysis Utilties.
U can Find it at this URL.
http://www.acl.lanl.gov/tau/
The problem with tau is that you have to add manual profiling tags in all ur
functions u want to profile.
In case you are using a UNIX based host say LINUX then,tau comes with a TK
based front end which graphically plots the profiling data,keep in mind that
TAU is multiproccesor aware.
I feel its the best suited profiling tool for RTEMS(its has a Open Sourse
GPL lind of a license also),Hope Joel  keeps that in mind!!!
Actually the manual tagging of sourcode can be over come using another tool
would at the same site called Program Database Toolkit.It automatically adds
tags,also displays functioncall graphs. et al.
I think some other tools for dynamic  runtime profiling  are also
available.....
TAU also features some USER EVENt options so that we can monitor resource
usage.
I think for using TAU your code should be compiled iwth g++ rather than gcc.
====================
Also if u try building the TAU in Cygwin,HEre how u should do it.
Just do
./configure -gnu -PROFILE -arch=i386_linux
You will get many errors ,ignore them
cd to the src/Profile directory and do a make there.You will find two .a lib
files are created .
Copy them to ur /lib directory
Now cd to the utils/src directory and do a make.
You will find some minor errors that can be easily corrected..
U will find there executables made,copy them to ur /bin
Try building some of the examples,Some of them require additional libraries
so leabe that
In the Makefile the LIB refers to a-lpthread remove that entry for Cygwin
has pthreads in it.
Afetr the example is built ,run it.
run pprof command in that dirctory ,U will find a tabular listing of the
profiling data.
Actually if u are in Linux ,if u run a racy command then,you get the
graphical display of profiling data.
===============================
SAY UR TARGET HAS A FILE SYSTEM THEN ,CAN A FILE BE CRAETED ON THE TARGET
FILE SYSTEM
AND LATER SOME HOME  TRANSMITTED TO THE HOST????????????????
IF THE ABOVE IS POSSIBLE THEN I THINK U CAN PROFILE UR APP RUNNING AT THE
TERGET ITSELF
c)There is also some profiler support in the SID Simulator by Red Hat.But I
have not used them.
Try looking into them.
Bye,
Kiran

------------------------------------------------------------------
----- Original Message -----
From: Aaron J. Grier <aaron at frye.com>
To: <rtems-users at oarcorp.com>
Sent: Saturday, August 25, 2001 3:09 AM
Subject: profiling with RTEMS


> I'd like to profile code running on my m68k-rtems platform...  gcc is
> gladly emitting calls to mcount with -pg, but where is mcount supposed
> to live?
>
> I think I've just convinced gcc to compile code for mcount into libgcc,
> but I'm not quite sure what to do next, and would hate to re-invent the
> wheel...
>
> how do I go about profiling my RTEMS application?
>
> --
>   Aaron J. Grier  |   Frye Electronics, Tigard, OR   |  aaron at frye.com
>      "In a few thousand years people will be scratching their heads
>        wondering how on earth the first computer was invented and
>           bootstrapped without a prior computer to do it with."
>                     --  Chris Malcolm, on comp.arch