On 06/27/2012 09:58 AM, Suthikulpanit, Suravee wrote:
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.
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
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"?