Solved the problem.
My apologies - perhaps I had not done enough home work. I am new to oprofile.
First off, the oprofile-0.9.2 on my embedded system had been patched.
So, I applied those patches on to my host Linux machine oprofile source files.
Then, I came to know about the opimport utility and with a small shell script ran it on the archive files and then I was able to obtain differential profile from opreport.
Thanks Maynard and once again sorry to have bothered you with a naive question.


On Thu, Sep 25, 2008 at 10:42 AM, Sherlock Holmes <> wrote:
Thanks a lot Maynard.
I used your patch and also added a small printf to it to display the version number it is reading.
Yes! there is a version number mismatch. It reads a garbage for the current version - (header.version = 268435456 while OPD_Version =16).  But the problem seems to be rooted in the archive.
I could not use tar command on my embedded system to tar the archive as tar was failing with a message that the file names in the oprofile archive were too long. So, I used the old cpio command which was able to archive the result directory. But when I extract in my Pentium based laptop, cpio warned me of reversed header in the archive and created the rest of the files( I had ignored the warning); the ascii files such as abi seem good but the binary ones are probably corrupted. Tried a few byte swapping options with cpio but they all fail. cpio compalined about odd number of bytes and opreport complained about bad magic number with the extracted files! So, now I am in a fix. Need to do more research?


On Tue, Sep 23, 2008 at 8:39 PM, Maynard Johnson <> wrote:
Sherlock Holmes wrote:
> Dear All,
> I did the following:
> 1. Installed and run oprofile in my PowerPC embedded system.
> 2. Used oparchive to archive the results - opr_run1
> 3. Optimized code and executed it under oprofile again.
> 4. Archived the results as in #2 - opr_run2
> 5. When I run opreport -l { archive:./opr_run1 } { archive:./opr_run2 } I
> get to see the differential profiling
> (as expected).
> All the steps above were on the embedded PowerPC e300 system. The version of
> oprofile used in 0.9.2 and
> I can't change it.
> However when I export the archive to my Linux machine running on i386 and
> oprofile version 0.9.4,
> and then running #5 there, I get the error message: oprofile: could not open
> unit mask description file
> /usr/local/share/oprofile//invalid cpu type/unit_masks
> So, I installed oprofile version 0.9.2 on my Linux machine and tried #5
> again. But this gave another error message:
> ../var/lib/...bin/bash/CPU_CLK.100000.0.all.all.all : Invalid argument. (I
> have omitted some path names here)
One possible cause for this error is a mismatch between the version of oprofile used to collect the profile and that which is used to generate the report.  Are you positive that you're using oprofile 0.9.2 in both cases?  Current oprofile detects this and prints a more helpful message.  I've attached a patch that you can apply to your oprofile installation where you are running opreport that incorporates this samplefile version detection code.  Can you try it out and let us know the result.


> Can someone help me please?
> I need to run the analyses offline since I dont get access to the embedded
> machine and the disk space
> available there is rather small.
> I appreciate you help.
> Regards.
> ------------------------------------------------------------------------
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & win great prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> ------------------------------------------------------------------------
> _______________________________________________
> oprofile-list mailing list