Profiling

Profiling

[Scott Dattalo]

I'm trying to collect profile info on my ARM-based application. I followed 
the directions on the SID web page regarding profiling. Basically, I added 
the two options "--gprof" and  "--trace-counter" to the arm-elf-sid 
invocation. I also created a .conf script. According to the SID 
documentation, the two lines:

connect-pin main perform-activity -> gprof sample
connect-pin main stopping -> gprof store

should be in the .conf file. I tried the conf file with and without these 
lines.

Now when I run the simulator (arm-elf-gdb which is built from the Insight 
5.2 sources), connect to sid, simulate, and exit, the file gmon.out is 
created. Cool.

Now when I run gprof:

$ gprof --flat-profile gmon.out

I get the error:

gprof: gmon.out: not in a.out format


Hmm. After reading the gprof docs, I added -pg to my CFLAGS options in my 
make files. Unfortunately, there is no profile library with which I can 
link. So my project doesn't build. Bummer.

Question: How *do* you profile? Do I need to build an arm-elf-gprof? Is 
there some other gprof option I need to add? Did I misunderstand the SID 
instructions?

Scott

Re: Profiling

[Frank Ch. Eigler]

Hi -


On Tue, Jun 25, 2002 at 05:03:05PM -0700, Scott Dattalo wrote:
> I'm trying to collect profile info on my ARM-based application. [...]
> connect-pin main perform-activity -> gprof sample
> connect-pin main stopping -> gprof store

The "perform-activity" pin may signal infrequently compared to
CPU instruction rates, so you will get a relatively low sample rate.
You could connect that gprof sample pin from another source, such as
the scheduler's CPU-bound NNN-output signal.

> [...]
> Now when I run gprof:
> $ gprof --flat-profile gmon.out
> I get the error:
> gprof: gmon.out: not in a.out format

This is a simple gprof usage error.  gprof implicitly looks for the 
file named gmon.out, but it doesn't know what *target executable* to
relate it to.  gprof needs to process the executable in order to
extract its symbol table, so that the PC sample addresses in gmon.out
can become sensible.  So, all you need to do is build the cross-gprof,
and run

	arm-elf-gprof file.exe

By the way, the "--flat-profile" option is not always needed any more,
as sid can collect call-graph profiling information from cooperating
cpu models.  (They need to drive a special c-call from subroutine
call semantics.)  I don't recall if the ARM cpu model includes the
few lines of code for this.  If you're interested in fuller profiling,
I'd be happy to give pointers for completing that few-minute job.


> Hmm. After reading the gprof docs, I added -pg to my CFLAGS options in my 
> make files. [...]

Right - this requests gcc to instrument the target code.
sid can profile uninstrumented target code.
(In some cases, sid can execute -pg-instrumented code and
produce a gmon.out file, but this requires many more pieces
of target software, and has some different properties.)


- FChE

Re: Profiling

[Scott Dattalo]

On Tue, 25 Jun 2002, Frank Ch. Eigler wrote:

> Hi -
> 
> 
> On Tue, Jun 25, 2002 at 05:03:05PM -0700, Scott Dattalo wrote:
> > I'm trying to collect profile info on my ARM-based application. [...]
> > connect-pin main perform-activity -> gprof sample
> > connect-pin main stopping -> gprof store
> 
> The "perform-activity" pin may signal infrequently compared to
> CPU instruction rates, so you will get a relatively low sample rate.
> You could connect that gprof sample pin from another source, such as
> the scheduler's CPU-bound NNN-output signal.
> 
> > [...]
> > Now when I run gprof:
> > $ gprof --flat-profile gmon.out
> > I get the error:
> > gprof: gmon.out: not in a.out format
> 
> This is a simple gprof usage error.  gprof implicitly looks for the 
> file named gmon.out, but it doesn't know what *target executable* to
> relate it to.  gprof needs to process the executable in order to
> extract its symbol table, so that the PC sample addresses in gmon.out
> can become sensible.  So, all you need to do is build the cross-gprof,
> and run
> 
> 	arm-elf-gprof file.exe

Yes, I surmised as much when I saw the SID screen shot with this command.

But the question I have is how do you build arm-elf-gprof (I posed this 
question to the eCos list as well, BTW)? When I follow the arm-elf tool 
chain build instructions, I get a whole lot of arm-elf-* files, but no 
gprof. I tried --enable-gprof as part of the binutil ./configure, but that 
didn't do it. Of course, I'm just guessing at this point...

BTW, this is where I got the arm-elf build instructions:
http://sources.redhat.com/ecos/tools/linux-arm-elf.html

Scott

Re: Profiling

[Frank Ch. Eigler]

Hi -

On Tue, Jun 25, 2002 at 07:01:39PM -0700, Scott Dattalo wrote:
> [...]
> But the question I have is how do you build arm-elf-gprof [...]

The gprof program, for historical reasons, is sometimes excluded
from a cross-targeted toolchain.  If you have a source tree with
a Cygnus configure script at the top level, or a gcc source tree,
then look for the "native_only" variable from the top-level
configure.in, remove "gprof".  Then reconfigure the build tree,
and run "make" in the gprof subdirectory.

- FChE

Re: Profiling

[Scott Dattalo]

On Tue, 25 Jun 2002, Frank Ch. Eigler wrote:

> Hi -
> 
> On Tue, Jun 25, 2002 at 07:01:39PM -0700, Scott Dattalo wrote:
> > [...]
> > But the question I have is how do you build arm-elf-gprof [...]
> 
> The gprof program, for historical reasons, is sometimes excluded
> from a cross-targeted toolchain.  If you have a source tree with
> a Cygnus configure script at the top level, or a gcc source tree,
> then look for the "native_only" variable from the top-level
> configure.in, remove "gprof".  Then reconfigure the build tree,
> and run "make" in the gprof subdirectory.

That did it!

Just to be clear, this is what I did:

I untar'd the binutils-2.12.1 tar ball and edited 
binutils-2.12.1/configure.in. There's a line containing "native_only" that 
several packages (like gprof, sed,...); I removed gprof from that list.

I then followed the instructions here for building binutils:
http://sources.redhat.com/ecos/tools/linux-arm-elf.html

and arm-elf-gprof was created! Score!

---

Now for profiling...

My application uses the eCos RTOS and consequently is linked with it. I 
discovered that you *can't* compile the source for profiling by adding -pg 
option as part of the CFLAGS. Okay, I'm lying; you can compile with the 
-pg option, but you get unresolved references when you link. I don't know 
if eCos can be configured for profiling or not. I'll check into that 
later. For the time being though, I don't need it. I was able to extract 
profiling info just fine without compiling the sources with -pg. Here's 
what I did:

1) Configured SID for profiling. I followed the instructions in the SID 
documentation. Essentially, I added --gprof and --trace-counter to the SID 
invocation. BTW, I also told SID to creat a configuration file by adding 
--save-temps and --no-run to the invocation. Once you have a configuration 
file, you can invoke SID by: sid configuration_file.conf.

2) Run the application. Again, following the instructions on the SID web 
page, I started sid and ran my application:

sid myconf.conf &
arm-elf-gdb myexecutable

in gdb, add these commands:

 (gdb) target remote localhost:2000
 (gdb) load
 (gdb) break main
 (gdb) cont

(note that this is a copy-n-paste from the SID faq)

I then stepped through my code and exited gdb when I was done.

3) looking at the results. Upon exiting gdb, the file "gmon.prof" is 
created. This contains the profile information. Use gprof to look at it:

arm-elf-gprof --flat-profile myexecutable

Without --flat-profile, gprof reports: 

arm-elf-gprof: gmon.out file is missing call-graph data

Also, you need to specify the executable to gprof and not the gmon.out 
file.

The first few lines of my profile look like this:


Flat profile:

Each sample counts as 1 tick.
  %   cumulative   self              self     total           
 time      tick      tick    calls  Tt/call  Tt/call  name    
 16.87   1009.00  1009.00                             __unpack_f
 16.57   2000.00   991.00                             __pack_f
 13.21   2790.00   790.00                             _fpadd_parts
  9.73   3372.00   582.00                             __floatsisf

------

And now I can go off and do some work!

Thanks for the info Frank.

Scott

PS. Sorry about the abruptly ending e-mail I sent to you privately. I was 
composing it for the whole list, but ran out of time. I shouldn't of even 
sent it.