Bug 211499

Summary: Option to return values from processor's native cpuid instruction
Product: [Developer tools] valgrind Reporter: William Cohen <wcohen>
Component: vexAssignee: Julian Seward <jseward>
Status: REPORTED ---    
Severity: wishlist CC: mark
Priority: NOR    
Version First Reported In: unspecified   
Target Milestone: ---   
Platform: Compiled Sources   
OS: Linux   
Latest Commit: Version Fixed/Implemented In:
Sentry Crash Report:
Attachments: Patch to control use of native cpuid instruction in code

Description William Cohen 2009-10-23 06:37:57 UTC 
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.
Comment 1 William Cohen 2009-12-30 16:14:07 UTC 
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).
Comment 2 Julian Seward 2010-02-21 14:21:23 UTC 
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.
Comment 3 William Cohen 2010-02-22 03:31:27 UTC 
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.