Community
Participate
Working Groups
Build Identifier: M20110909-1335 The method org.eclipse.linuxtools.oprofile.core.opxml.EventIdCache.getUnitMaskType(String) reads /usr/share/oprofile/<cpu_type>/events and /usr/share/oprofile/<cpu_type>/unit_masks instead of simply using the output from ophelp -X. Furthermore, because of the approach that was taken, the code actually processes the files incorrectly because it doesn't pay any attention to the "include:" directives in the files it reads. For example, on my x86_64 laptop, if I read /usr/share/oprofile/i386/core_i7/unit_masks, the only contents of that file is "include:i386/nehalem". The above method doesn't go and read the included file, so it's doesn't find any unit masks. The implementation should change to use "ophelp -X" because it will do all of that include processing for you, and you will be able to use standard XML parsing the get the needed information. Reproducible: Always
This functionality made it into oprofile upstream as commit f3c4ab9d2a9bc3aa2236ee3763ad1a39ba190686 (I was aware of the issues surrounding unit mask types and wanted ophelp to provide this functionality). This is newin 0.9.7 but I think it's worth having as opposed to relying on the reading various files manually. Thanks for the bug report.
(In reply to comment #1) > This functionality made it into oprofile upstream as commit > f3c4ab9d2a9bc3aa2236ee3763ad1a39ba190686 (I was aware of the issues surrounding > unit mask types and wanted ophelp to provide this functionality). This is newin > 0.9.7 but I think it's worth having as opposed to relying on the reading > various files manually. Thanks for the bug report. I talked with one of the OProfile maintainers today (Maynard Johnson - mpjohn@us.ibm.com), and as a result I think that it might be a good idea to switch to using the output of "ophelp -X" exclusively. On older systems (e.g. SLES 10), ophelp -X will simply generate an error, because the -X option is not supported at all. However, we should be able to detect this from inside of the plug-in and issue an error that the user needs to upgrade his oprofile to a newer version. The maintainer says that the oprofile kernel ABI hasn't changed in a very long time, so you should be able to download the latest oprofile source from sourceforge and build it, producing new ophelp and opcontrol executables, which by default will install in /usr/local/bin. Of course, this means that the location of the op* tools has to be configurable! If plug-in runs ophelp -X and notes that the schemaversion is not 1.1 or higher, it can tell the user that they need a newer version of oprofile installed. If the schemaversion is 1.1 or higher, you can expect that the category attribute will be present in the ophelp -X output.
I have a proposed patch I'm testing out but I'm not sure sure about dropping the functionality that looks inside /usr/share/oprofile. I'd rather have that around for those using an older version of oprofile installed on the standard path.
Created attachment 208691 [details] Patch
This looks like a good solution to me. Thanks!
Committed as 4b28814587e8faf1943acbb18e17a78508034d15.
Resolving as fixed.
