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.
Maynard Johnson <maynardj@...> writes:
> 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.
FWIW I had the same problem until I cleared the $PATH
ak@... -- Speaking for myself only