Version: (using Devel) OS: Linux Installed from: Compiled sources Valgrind always fakes the cpuid instructions on the machine. It never uses the actual results produced by the native processor's cpuid instruction. This helps ensure that valgrind doesn't end up trying to execute instruction from a dynamically selected library it doesn't understand. However there are programs where it would be useful to allow as an option the results of the native processor's cpuid instruction. Programs such as performance monitoring libraries (PAPI) need to identify the processor accurately to know what events to events to monitor. PAPI doesn't have dynamically selected code. It just needs to know the actual results of the cpuid instructions. It would be nice to have a command-line option to select the native processor's CPUID instruction results.
Created attachment 39464 [details] Patch to control use of native cpuid instruction in code This patch allows the user to control the use of the native cpuid instruction. The patch adds the following option: --vex-native-cpuid=[yes|no] The default behavior is same as before (--vex-native-cpuid=no is the default).
Not sure I understand. Suppose we run PAPI on V with --vex-native-cpuid=yes. PAPI reads the real CPUID, fine, and then it somehow sets up event monitoring via Vex for some CPU which Vex doesn't support? and Vex doesn't support any performance monitoring registers or wotnot. w/ apologies in advance if the above question is meaningless. I have no idea how this performance monitoring stuff is presented in user-space.
The performance monitoring stuff uses kernel calls to do the actual set up of the performance counters and read the performance counters. The place that the PAPI needs to use CPUID instruction is to identify the specific processor implementation (e.g. Core 2 duo or Pentium III) and map the event to the magic number for the performance event. Speaking from experience PAPI will work with valgrind/VEX if it is allowed to get actual results from the CPUID instruction. It is quite understandable that VEX has a limited set of CPUID it uses to avoid encountering an instruction that is unhandled by VEX. The suggested patch does not change that default behavior for just that reason.