GP2X Gprof


Squidge

Certified Guru
Joined
Nov 16, 2003
Messages
8,493
Location
UK
Website
Visit site
I'm trying to profile some code on the 2x, I've compiled with -pg, and it spits out a 'gmon.out' file. However, this file seems to be mostly empty (seems to be about 52 bytes of data, and 168K of zero bytes), and running gprog gives the message 'gprof: gmon.out file is missing call-graph data'

Just in case it was my build of GCC, I installed DevKitGP2X, but the same thing occurs - although with a slightly larger 'gmon.out' file.

Am I doing something stupid here? Do I need to include something else other than just '-pg' ?
 
It seems to work for me - using open2x under Linux. I just compiled and linked with -pg, ran the program on the gp2x, copied the gmon.out back to the PC, and ran:

Code:
arm-open2x-linux-gprof test gmon.out

My program terminated far too quickly to actually get any data though - it was just doing some maths, obviously not enough! Still, it gave the function call counts and call graph, just all the times were zero.

My gmon.out is also mostly zeros - I guess that's normal. There's some nonzero data at the end though, as well as the stuff at the start.

:wq
 
Ok, solved. Seems like GCC doesn't like GCC doesn't like you using optimization when using profiling. Now that seems to be completely different to the other profilers I've used, which insist that you do to ensure the fastest code possible (I think they go on the assumption of "let the compiler do the most work for you first")
 
I used this makefile fragment:

Code:
test: test.c
        $(CC) -o $@ $^ -static -pg

so no -g option, though I wouldn't have thought that would matter. Try downloading my executable and gmon.out, and see if they work with your versions of gprof...

http://www.glost.eclipse.co.uk/gfoot/gp2x/profile_test.zip

As far as I know, -pg causes the compiler to instrument the code, and causes the linker to use different startup code to create the file. I guess if anything failed in your case it would have to be the compilation phase. -pg also causes the linker to link an instrumented libc, but it's not critical if it can't find it, you just don't get a breakdown inside uninstrumented code. My profiling results didn't list any libc functions so I guess I don't have the instrumented library.

Edit: Optimization shouldn't prevent profiling - profiling unoptimized builds isn't that useful really! I get the same results as you though - with optimization turned on, the gmon.out is bogus. I guess this is probably a gcc bug.
 
It looks like this is a known issue with arm gcc, though it's claimed fixed in newer gcc versions. One work-around is to disable the omit-frame-pointer optimisation, using -fno-omit-frame-pointer. You might need to put that after the -O2, or it might switch it back on or something - I don't know whether order is significant here.

I've also found it sometimes necessary to sync after running the program - I got a lot of truncated gmon.out files by going straight to the USB connection screen, and putting a sync in my script seemed to fix it.
 
Yup, I tried it in GCC for another arch and it worked as expected. I'm using GCC for ARM 4.0.3, so I don't think it's been fixed. Will try your -fno-omit-frame-pointer suggestion though.

I wonder if the pre/post function call user-callbacks work under the ARM GCC when optimization is enabled? If so, user written profiling could be another workaround.
 
Back
Top