On 06/27/2012 09:58 AM, Suthikulpanit, Suravee wrote:

I'm testing my patch and run into some issue.  Looking at the logic in the "libop/op_cpu_type.c".  My understanding is that if the oprofile driver (/dev/oprofile) is not loaded, it will try to capture the cpu_type from the cpuid.  And that's the logic I am testing for detecting AMD processors.

However, I trace the execution and seems like everything is checking out fine.  My code return cpu_type = 44 (x86-64/family10) as expected.  However, I keep getting the error:

Using samples dir /root/testOperf/oprofile_data/samples
Unable to open cpu_type file for reading
Make sure you have done opcontrol --init
cpu_type 'unset' is not valid
you should upgrade oprofile or force the use of timer mode
Error retrieving info for event DISPATCHED_FPU_OPS:5000:0x3f:1:1

This doesn't make sense to me since the message "Unable to open cpu_type file for reading" should not have come up any more.  !!!!!

Turn out, the root cause was in the "pe_profiling/operf.cpp" where it was trying to launch using "ophelp".  Here, it uses "ophelp" that is first in the PATH which is the older version.  Basically, this is a path issue.  My concern is that, shouldn't we use "<prefix>/bin/ophelp" instead of "ophelp"?
Yes.  The same goes for operf's invocation of opjitconv.  They should both use OP_BINDIR. This error can only occur when invoking operf using its full pathname, and I guess I just always had my PATH set when running it. Thanks for catching that.  I'll make a patch.