Maynard Johnson | 21 Nov 23:38 2014
Picon

[PATCH] Add a check to ensure event codes in events files fit in an integer

This patch has already been pushed upstream.

-----------------------------------------------------------------

Add a check to ensure event codes in events files fit in an integer

The read_events() function in libop/op_events.c is enhanced to
validate that the hex codes found in events files are not too big
to fit in an integer, since the rest of oprofile assumes hex codes
are integers.  This check will execute whenever ocount or operf is
run, as well as when doing 'make check' or 'make distcheck'.

Signed-off-by: Maynard Johnson <maynardj <at> us.ibm.com>
---
 libop/op_events.c |   17 ++++++++++++++++-
 1 files changed, 16 insertions(+), 1 deletions(-)

diff --git a/libop/op_events.c b/libop/op_events.c
index 29dc2f3..99266c6 100644
--- a/libop/op_events.c
+++ b/libop/op_events.c
 <at>  <at>  -498,6 +498,7  <at>  <at>  static void read_events(char const * file)
 	int seen_event, seen_counters, seen_um, seen_minimum, seen_name, seen_ext;
 	FILE * fp = fopen(file, "r");
 	int tags;
+	int fail = 0;

 	if (!fp) {
 		fprintf(stderr, "oprofile: could not open event description file %s\n", file);
 <at>  <at>  -510,6 +511,8  <at>  <at>  static void read_events(char const * file)
(Continue reading)

Maynard Johnson | 21 Nov 20:56 2014
Picon

[PATCH v2] Add support for IBM Power event codes longer than sizeof int

Add support for IBM Power event codes longer than sizeof int

A small number of events on newer IBM Power processors have event codes
that are larger than sizeof(int). Rather than change the width of the
event code everywhere to be a long int (which would include having to
change the sample file format), we have defined some internal-use-only
unit masks for those events. These unit masks are not shown in the ophelp
output, and IBM Power users should never use them in event specifications;
instead, they should use the usual 'null' unit mask value of '0x0' in event
specifications -- e.g.,
       PM_L1MISS_LAT_EXC_256:0x0:0:1

See libpe_utils/op_pe_utils.cpp:_get_event_code for how these unit masks are
used.

Signed-off-by: Maynard Johnson <maynardj <at> us.ibm.com>
---
 events/ppc64/power8/events     |   16 ++++++++--------
 events/ppc64/power8/unit_masks |    8 ++++++++
 libop/op_events.c              |   39 +++++++++++++++++++++++++++++++++++++--
 libop/op_events.h              |    2 +-
 libpe_utils/op_pe_utils.cpp    |   15 +++++++++++----
 utils/ophelp.c                 |    2 +-
 6 files changed, 66 insertions(+), 16 deletions(-)

diff --git a/events/ppc64/power8/events b/events/ppc64/power8/events
index cc1163a..012ca89 100644
--- a/events/ppc64/power8/events
+++ b/events/ppc64/power8/events
 <at>  <at>  -451,10 +451,10  <at>  <at>  event:0x30a8 counters:0,1,2,3 um:zero minimum:10000 name:PM_ISU_REJ_VS0 : VS0 IS
(Continue reading)

Maynard Johnson | 19 Nov 23:51 2014
Picon

[PATCH] Add support for IBM Power event codes longer than sizeof int

Hi, Henry,
The patch below addresses the issue you raised yesterday on the oprofile
list (subject "PM_L1MISS_LAT_EXC_xxx events").  At first, I looked into
what it would take to add general support for long event codes, but I soon
discovered that it would entail a change to the sample file format, and
I was loathe to do that just for eight events from IBM POWER8.  I verified
that there are no other events for any architecture other than these eight
that have event codes longer than an integer. So I implemented a bit of a
hack, using the concept of a unit mask as an event qualifier. It's an OK
fit, conceptually, it's just a bit hacky because no other ppc64 events
use unit masks.  But the fix was fairly small and simple, so I think it's
fine.

Please give it a test and let me know how it works for you.

Thanks!
-Maynard

------------------------------------------------------------------------

Add support for IBM Power event codes longer than sizeof int

A small number of events on newer IBM Power processors have event codes
that are larger than sizeof(int). Rather than change the width of the
event code everywhere to be a long int (which would include having to
change the sample file format), we have defined some internal-use-only
unit masks for those events. These unit masks are not shown in the ophelp
output, and IBM Power users should never use them in event specifications;
instead, they should use the usual 'null' unit mask value of '0x0' in event
specifications -- e.g.,
(Continue reading)

Henry May | 19 Nov 02:47 2014
Picon

PM_L1MISS_LAT_EXC_xxx events

I have RHEL7 on a P8 and am unable to collect any of the PM_L1MISS_LAT_EXC_xxx events with ocount.  Any suggestions?

[root <at> pftul3 ~]# /opt/at7.0/bin/ocount -s -c -b -e PM_L1MISS_LAT_EXC_32
perf_event_open failed with Invalid argument
Caught runtime error while setting up counters
Internal Error.  Perf event setup failed.
Error running ocount

Henry May
IBM InfoSphere Streams Performance
hjmay <at> us.ibm.com
720-342-8873
Tie: 963-8873
------------------------------------------------------------------------------
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration & more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=157005751&iu=/4140/ostg.clktrk
_______________________________________________
oprofile-list mailing list
oprofile-list <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oprofile-list
Richard Purdie | 7 Nov 13:32 2014

[PATCH] opjitconv: Fix incorrect open() flag

When using compile fortification options on a mips build we saw:

| In file included from /media/build1/poky/build/tmp/sysroots/qemumips/usr/include/fcntl.h:302:0,
|                  from opjitconv.c:25:
| In function 'open',
|     inlined from 'copy_dumpfile' at opjitconv.c:219:6:
| /media/build1/poky/build/tmp/sysroots/qemumips/usr/include/bits/fcntl2.h:50:4: error: call
to '__open_missing_mode' declared with attribute error: open with O_CREAT in second argument needs 3 arguments
|     __open_missing_mode ();
|     ^
| Makefile:440: recipe for target 'opjitconv.o' failed

Why does this only happen on mips? mips has:

O_CREAT = 0x100 and S_IRUSR = 0400 and these (in hex and otcal) are equivalent. 
Most other platforms have O_CREAT = 0100.

Obviously the call is simply wrong so fix it...

Signed-off-by: Richard Purdie <richard.purdie <at> linuxfoundation.org>

Index: oprofile-1.0.0/opjitconv/opjitconv.c
===================================================================
--- oprofile-1.0.0.orig/opjitconv/opjitconv.c	2014-09-12 14:39:47.000000000 +0000
+++ oprofile-1.0.0/opjitconv/opjitconv.c	2014-11-06 13:14:25.941639003 +0000
 <at>  <at>  -216,7 +216,7  <at>  <at> 
 	int file_locked = 0;
 	unsigned int usecs_waited = 0;
 	int rc = OP_JIT_CONV_OK;
-	int fd = open(dumpfile, S_IRUSR);
+	int fd = open(dumpfile, O_CREAT, S_IRUSR|S_IWUSR);
 	if (fd < 0) {
 		perror("opjitconv failed to open JIT dumpfile");
 		return OP_JIT_CONV_FAIL;

------------------------------------------------------------------------------
Maynard Johnson | 27 Oct 23:59 2014
Picon

[PATCH] Flesh out oparchive procedure and fix other minor doc errors

Flesh out oparchive procedure and fix other minor doc errors

The oparchive man page does not do a very good job of documenting
how oparchive is intended to be used.  This patch addresses that
issue, in particular by directing the reader to the user manual
where there is much more detail to be found.

Additionally, this patch makes a few other minor doc fixups,
such as fixing an example shell script in the chapter on opimport
(a comment line did not have a "#" at the beginning of the line)
and removing a reference to qt stuff in the user manual. The patch
also cleans up the oprofile man page, updating it to reflect the
change from opcontrol operf.

Signed-off-by: Maynard Johnson <maynardj <at> us.ibm.com>
---
 doc/oparchive.1.in |   24 ++++++++++++++++++------
 doc/oprofile.1.in  |   51 ++++++++++++++++++++++++++++++++++++---------------
 doc/oprofile.xml   |   24 ++++++++++++++++--------
 3 files changed, 70 insertions(+), 29 deletions(-)

diff --git a/doc/oparchive.1.in b/doc/oparchive.1.in
index 753d6d5..b188654 100644
--- a/doc/oparchive.1.in
+++ b/doc/oparchive.1.in
 <at>  <at>  -13,12 +13,21  <at>  <at>  oparchive \- produce archive of oprofile data for offline analysis
 [directory]
 .SH DESCRIPTION

+The
 .B oparchive
-generates a directory populated with executable, debug, and oprofile sample
-files. This directory can be move to another machine via tar and analyzed
-without further use of the data collection machine. See oprofile(1) for how
-to write profile specifications.
-
+utility is commonly used for collecting profile data on a "target"
+system for future offline analysis on a different ("host") machine.
+.B oparchive
+creates a directory populated with executables, libraries, debuginfo files, and oprofile sample
+files. This directory can be tar'ed up and moved to another machine to be analyzed
+without further use of the target machine. Using
+.BI opreport
+and other post-profiling tools against archived data requires the use of the
+.I archive:<archived-dir>
+specification. See oprofile(1) for how to write profile specifications.
+A complete description of offline analysis can be found in the chapter titled
+.I Analyzing profile data on another system (oparchive)
+of the OProfile user manual. (See the user manual URL in the "SEE ALSO" section below.)
 .SH OPTIONS
 .TP
 .BI "--help / -? / --usage"
 <at>  <at>  -79,5 +88,8  <at>  <at>  The location of the generated sample files.
 This man page is current for  <at> PACKAGE <at> - <at> VERSION <at> .

 .SH SEE ALSO
-.BR  <at> OP_DOCDIR <at> ,
+.BR file:// <at> OP_DOCDIR <at> oprofile.html#oparchive
+.br
+.BR opimport(1)
+.br
 .BR oprofile(1)
diff --git a/doc/oprofile.1.in b/doc/oprofile.1.in
index 550954a..c477843 100644
--- a/doc/oprofile.1.in
+++ b/doc/oprofile.1.in
 <at>  <at>  -1,9 +1,21  <at>  <at> 
 .TH OPROFILE 1 " <at> DATE <at> " "oprofile  <at> VERSION <at> "
 .UC 4
 .SH NAME
-oprofile \- a system-wide profiler
+oprofile \- a statistical profiler for Linux systems, capable of profiling all running code
+at low overhead; also included is a set of post-profiling analysis tools, as well as a simple
+event counting tool
 .SH SYNOPSIS
 .br
+.B operf
+[
+.I options
+]
+.br
+.B ocount
+[
+.I options
+]
+.br
 .B opreport
 [
 .I options
 <at>  <at>  -30,16 +42,21  <at>  <at>  oprofile \- a system-wide profiler
 .br
 .SH DESCRIPTION
 OProfile is a profiling system for systems running Linux
-2.6 and greater. Profiling runs transparently in the background and profile
-data can be collected at any time. OProfile makes use of the hardware
-performance counters provided on Intel, AMD, and other processors,
-and uses a timer-interrupt based mechanism on CPUs without counters.
-OProfile can profile the whole system in high detail.
+2.6.31 and greater. OProfile makes use of the hardware
+performance counters provided on Intel, AMD, and other processors.
+OProfile can profile a selected program or process or the whole system.
+OProfile can also be used to collect cumulative event counts at the
+application, process, or system level.
 .br
 For a gentle guide to using OProfile, please read the HTML documentation
 listed in SEE ALSO.
 .br
-.SH OPCONTROL
+.SH OPERF
+.B operf
+is a performance profiler tool for Linux.
+.SH OCOUNT
+.B ocount
+is an event counting tool for Linux.
 .SH OPREPORT
 .B opreport
 gives image and symbol-based profile summaries for the whole system or
 <at>  <at>  -55,14 +72,16  <at>  <at>  produces oprofile archive for offline analysis
 can produce a gprof-format profile for a single binary.

 .SH PROFILE SPECIFICATIONS
-All of the post-profiling tools can take profile specifications,
-which is some combination of the following parameters. Enclosing
-part of a profile specification in curly braces { } can be used
+Various optional profile specifications may be used with the
+post-profiling tools. A profile specification is some combination of the parameters
+listed below. (
+.BR Note :
+Enclosing part of a profile specification in curly braces { } can be used
 for differential profiles with
-.B opreport
-; the braces
+.BR opreport ,
+but the braces
 .B must
-be surrounded by whitespace.
+be surrounded by whitespace.)

 .TP
 .BI "archive:"archive
 <at>  <at>  -83,7 +102,7  <at>  <at>  A comma-separated list of sessions to exclude.
 .BI "image:"imagelist
 A comma-separated list of image names to resolve. Each entry may be relative
 path, glob-style name, or full path, e.g.
-opreport 'image:/usr/bin/oprofiled,*op*,./oprofpp'
+opreport 'image:/usr/bin/operf,*op*,./oprofpp'
 .br
 .TP
 .BI "image-exclude:"imagelist
 <at>  <at>  -135,7 +154,7  <at>  <at>  tgid: to restrict the results to particular threads within a process.
 This is only useful when using per-process profile separation.

 .SH ENVIRONMENT
-No special environment variables are recognized by oprofile.
+No special environment variables are recognized by OProfile.

 .SH FILES
 .TP
 <at>  <at>  -163,6 +182,8  <at>  <at>  This man page is current for  <at> PACKAGE <at> - <at> VERSION <at> .

 .SH SEE ALSO
 .BR  <at> OP_DOCDIR <at> ,
+.BR operf(1),
+.BR ocount(1),
 .BR opreport(1),
 .BR opannotate(1),
 .BR oparchive(1),
diff --git a/doc/oprofile.xml b/doc/oprofile.xml
index 01cd309..325ef6f 100644
--- a/doc/oprofile.xml
+++ b/doc/oprofile.xml
 <at>  <at>  -310,13 +310,6  <at>  <at>  is often all you need, but note these arguments to <command>./configure</command
 			</note> 
 		</listitem>
 	</varlistentry>
-	<varlistentry>
-		<term><option>--with-qt-dir/includes/libraries</option></term>
-		<listitem><para>
-			Specify the location of Qt headers and libraries. It defaults to searching in
-			<constant>$QTDIR</constant> if these are not specified.
-		</para></listitem>
-	</varlistentry>
 	<varlistentry id="disable-werror">
 		<term><option>--disable-werror</option></term>
 		<listitem><para>
 <at>  <at>  -2187,7 +2180,7  <at>  <at>  Show version.
     from the target system.
 <screen>
 #!/bin/bash
-Usage: my-import.sh &lt;input-abi-pathname&gt;
+#Usage: my-import.sh &lt;foreign-abi-fullpathname&gt;

 # NOTE: Start from the "samples" directory containing the "current" directory
 # to be imported
 <at>  <at>  -2207,6 +2200,21  <at>  <at>  $cd profile1/var/lib/oprofile/samples
 $my-import.sh `pwd`/../abi
 </screen>
 </para>
+<para>
+If the OProfile ABI is truly different on host and target machines, then the end result of running the
+above script will place the converted (i.e., imported) files into the <filename>current-imported</filename>
+directory.  By default, <command>opreport</command> and other post-profiling tools will look for samples
+in <filename>samples/current</filename> of the specified session directory.  So you should either rename
+<filename>current-imported</filename> to <filename>current</filename> or specify the session
specification of
+<command>session:current-imported</command> when running post-profiling tools.
+</para>
+<para>
+If the OProfile ABI is the same on the host and target machines, the <command>my-import.sh</command> script
+will print the following message for each sample file:
+<screen>
+input abi is identical to native. no conversion necessary.
+</screen>
+</para>
 <sect2 id="opimport-details">
 <title>Usage of <command>opimport</command></title>

--

-- 
1.7.1

------------------------------------------------------------------------------
Maynard Johnson | 17 Oct 18:30 2014
Picon

Transition of OProfile maintainership

To the whole OProfile community:

After 6 years of serving in the role of lead maintainer for the OProfile project, it's time for me to pass the
baton to someone else. I'll be retiring in late December, so I would like to have this transition completed
by early December.  Currently, the project is in pretty stable condition, with just a few open bugs and
feature requests. The primary task of the lead maintainer is to ensure submitted patches are
well-reviewed and tested before being committed.  Sometimes those reviews are handed off to other
community members who have the necessary expertise (in particular, architecture-specific patches are
usually reviewed by one of the architecture sub-maintainers on cc).  For arch-independent patches,
reviews from any community members are helpful, but in reality, the lead maintainer ha
 s the final say and so must also review such patches. Another part of the job is to help answer questions that
are posted to the mailing list. Traffic on the list is pretty low these days, !
 so not a l
ot of time is required for this. 

I encourage all who are interested in this opportunity to contact me, and we can discuss it. Feel free to do so
in a private response if you prefer. Thanks.

-Maynard

------------------------------------------------------------------------------
Comprehensive Server Monitoring with Site24x7.
Monitor 10 servers for $9/Month.
Get alerted through email, SMS, voice calls or mobile push notifications.
Take corrective actions from your mobile device.
http://p.sf.net/sfu/Zoho
Maynard Johnson | 17 Oct 16:14 2014
Picon

Re: operf jit problem. No anon samples?

On 10/16/2014 06:46 PM, Maurice Marks wrote:
> Sorry. AFAIK It worked at one time:
Hi, Maurice,
In future, please don't remove oprofile-list from cc, since we often rely on the community at large to help
answer questions.
> 
>  http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20090629/080117.html
I talked to a colleague of mine here at IBM who's involved with LLVM (although, not specifically with this
area).  He said that this oprofile support was for the "old" JIT, and the new  MCJIT does not yet have the
oprofile support, as far as he knew. He suggests you post a message to the LLVM mailing list -- http://lists.cs.uiuc.edu/mailman/listinfo/llvmdev.
> 
>  and more recently:
> 
> http://rubini.us/2013/03/20/profiling-jitted-ruby-code-with-oprofile/
> 
> Regarding the anonymous mapping. My understanding is that malloc will grab memory from the heap if its
relatively small, but do an mmap call to get larger chunks from the kernel  which are marked anonymous. I
guess I didn't understand the difference from oprofile's point of view.
> If it regarded the heap as part of lli's address space then it should have attributed its pc samples to lli
not ld.so, shouldn't it?
The heap address returned from malloc *is* part of lli's address space.  And if that truly is where LLVM is
putting compiled code, then, as I said earlier, a deep dive debugging session would be needed to figure out
why samples are being attributed to ld.so.  Go ahead and knock yourself out, but you might want to check in
with LLVM developers first to see if it would be worthwhile doing -- i.e., if newer JIT really does not have
support for oprofile yet as my colleague stated.

-Maynard
> If it was outside of lli's space, in anonymous memory then it could be "anon".
> 
> I might have to make up a much larger jit example to test this theory.
> 
> 
> 

------------------------------------------------------------------------------
Comprehensive Server Monitoring with Site24x7.
Monitor 10 servers for $9/Month.
Get alerted through email, SMS, voice calls or mobile push notifications.
Take corrective actions from your mobile device.
http://p.sf.net/sfu/Zoho
Maynard Johnson | 16 Oct 23:59 2014
Picon

Re: operf jit problem. No anon samples?

On 10/16/2014 02:09 PM, Maurice Marks wrote:
> Thanks Maynard. I really appreciate your help with this.
> 
>  I made two versions of lli (the llvm interpreter that Jits code, then runs it). One is linked with an llvm
that has oprofile support (/usr/local/bin/lii), one linked with llvm that has no such support built in. (/usr/bin/lli)
> 
> The runs below (on AMD)  show that there are no "anon" samples reported even with no llvm support for oprofile.
> However - there is a clue. This time  I ran opreport with Verbose debug and it reports a discrepancy between
the number
> of samples counted and how many were attributed to DSOs. Plus there are 4 lines of "start_offset is now 0"
which I don't understand but you might.
Regarding the message about the discrepancy, see the opreport man page, under the "--symbols" option, for
an explanation. But if the LLVM JITed code is really being loaded into the heap, then I'm at a loss to explain
why the majority of your sample addresses seem to be in the range of memory where
/lib/x86_64-linux-gnu/ld-2.19.so was loaded. A deep dive debugging session would be needed to compare
the process's memory mappings (/proc/≤pid>/maps) with the sample addresses being collected by operf
(which can be see using "-V convert" option.

As for the "start_offset is now 0", it's just informational goop for debugging purposes, and these are not unusual.
> 
> Looking at your response I have a question about "anonymous memory mappings". When you say that the JVM's
jit puts code in anonymous memory mappings, is there something it does specifically to advise oprofile of
the range of addresses for jit'd code?
See http://oprofile.sourceforge.net/doc/devel/developing.html, "Chapter 1. Developing a new JIT
agent".  It states the following:

  Ensure your virtual machine provides an API that, at minimum, can provide the following information about
dynamically compiled code:
    - Notification when compilation occurs
    - Name of the symbol (i.e., function or class/method, etc.)
    - *Address in anonymous memory where the compiled code was loaded*
    - Length of the compiled code segment

So as implemented now, oprofile's JIT support does not support JITed code loaded anywhere but in anonymous
memory -- JITed code in the heap is not supported.

Now, this is the third time I've asked this question, and I would really appreciate an answer.  Have you (or
anyone else you know) used oprofile successfully in the past to profile LLVM JITed code?  From google
searches, I see that the feature seems to have been around since early 2013 (see
http://lists.cs.uiuc.edu/pipermail/llvmdev/2013-March/060111.html), but maybe that was some
experimental branch (my ignorance of LLVM is showing).  But if it's never worked, it's odd no one has ever
asked about it on the oprofile-list before.

-Maynard
> 
> The llvm jit (and probably others) just grab memory from the heap, generate code into it, mark the region
executable and execute the code.
> 
> I should add that I've done some experiments with perf, which has a facility (also a file in /tmp) to let perf
know about the name, address and length of jit'd code at run time. Using that scheme perf is able to
attribute samples in jit'd code to a particular name and range.
> Personally I found that it was unreliable, that is, it did identify jit'd code  ranges, but I didn't believe
the relative counts. They didn't make sense, especially with perf top, in real time. And I'd really prefer
to use oprofile if I can figure out the problem.
> 
> 
> 
> dad <at> piled:/media/dad/work$ /usr/local/bin/operf -Vdebug -e CPU_CLK_UNHALTED:1000000
/usr/bin/lli loopy.ll
> Using samples dir /media/dad/work/oprofile_data/samples
> Kernel profiling is not possible with current system config.
> Set /proc/sys/kernel/kptr_restrict to 0 to collect kernel samples.
> Exec args are: lli loopy.ll
> telling child to start app
> app 17499 is running
> Forking read pid
> parent says start app /usr/bin/lli
> going into waitpid on profiled app 17499
> operf: Profiler started
> Successfully read header info for sample data
> Converting operf data to oprofile sample data format
> sample type is 43
> fib(43) == 701408733
> profiled app ended normally.
> operf recording finished.
> Total bytes recorded from perf events: 620120
> operf-record process returned OK
> operf_read: Total bytes received from operf_record process: 619888
> Calling _do_jitdump_convert
> start time/end time is 1413484783/1413484788
> JIT dump processing complete.
> operf-read process returned OK
> 
> Profiling done.
> dad <at> piled:/media/dad/work$ /usr/local/bin/opreport -V debug,stats -l /usr/bin/lli
> Using /media/dad/work/oprofile_data/samples/ for samples directory.
> CPU: AMD64 family15h, speed 4000 MHz (estimated)
> Counted CPU_CLK_UNHALTED events (CPU Clocks not Halted) with a unit mask of 0x00 (No unit mask) count 1000000
> start_offset is now 0
> INFO: Sample counts differ:  Module summary count: 19294; total symbols count: 2
>     image name: /lib/x86_64-linux-gnu/ld-2.19.so <http://ld-2.19.so>
> start_offset is now 0
> start_offset is now 0
> start_offset is now 0
> samples  %        image name               symbol name
> 24       58.5366  no-vmlinux               /no-vmlinux
> 12       29.2683  lli                      /usr/bin/lli
> 1         2.4390  ld-2.19.so <http://ld-2.19.so>               check_match.9458
> 1         2.4390  ld-2.19.so <http://ld-2.19.so>               do_lookup_x
> 1         2.4390  libc-2.19.so <http://libc-2.19.so>             __GI___strcmp_ssse3
> 1         2.4390  libc-2.19.so <http://libc-2.19.so>             _int_free
> 1         2.4390  libc-2.19.so <http://libc-2.19.so>             malloc_consolidate
> dad <at> piled:/media/dad/work$
> 
> 
> On Thu, Oct 16, 2014 at 12:59 PM, Maynard Johnson <maynardj <at> us.ibm.com <mailto:maynardj <at> us.ibm.com>> wrote:
> 
>     On 10/16/2014 11:31 AM, Maurice Marks wrote:
>     > I don't think that was the problem. Just in case it was involved I tried changing the event count to
5000000. That reduced the sample count but the problem of missing anon samples was just the same. There was
one other thing that worried me. Most of my testing was on a VM (VMware Player 6.0.3) which, although it
makes the performance counters available, isn't perfect. However operf works just fine on it with  non Jit applications.
>     >
>     [snip]
>     > dad <at> piled:/media/dad/work$ opreport
>     > Using /media/dad/work/oprofile_data/samples/ for samples directory.
>     > CPU: AMD64 family15h, speed 4000 MHz (estimated)
>     > Counted CPU_CLK_UNHALTED events (CPU Clocks not Halted) with a unit mask of 0x00 (No unit mask) count 1000000
>     > CPU_CLK_UNHALT...|
>     >   samples|      %|
>     > ------------------
>     >     19536 100.000 lli
>     >     CPU_CLK_UNHALT...|
>     >       samples|      %|
>     >     ------------------
>     >         19339 98.9916 ld-2.19.so <http://ld-2.19.so> <http://ld-2.19.so>
>     >            60  0.3071 no-vmlinux
>     >            48  0.2457 libLLVMCore.so
>     >            37  0.1894 libLLVMCodeGen.so
>     >            15  0.0768 libLLVMSelectionDAG.so
>     >            10  0.0512 libLLVMSupport.so
>     >             6  0.0307 libLLVMX86CodeGen.so
>     >             5  0.0256 libc-2.19.so <http://libc-2.19.so> <http://libc-2.19.so>
>     >             5  0.0256 libpthread-2.19.so <http://libpthread-2.19.so> <http://libpthread-2.19.so>
>     >             3  0.0154 libstdc++.so.6.0.20
>     >             2  0.0102 lli
>     >             2  0.0102 libLLVMAsmParser.so
>     >             1  0.0051 libLLVMAnalysis.so
>     >             ...
>     >
>     [snip]
>     > Other possibilities?
>     >
>     > Is there an oprofile test for the jit functionality I can try?
>     Maurice,
>     Please try profiling the LLVM app without the oprofile JIT support. Not sure how you do that, but I presume
you know.  The results you get should look similar to what I get when I profile a java app without passing the
-agentlib or -agentpath to the JVM; i.e.,
> 
>     -------------------------------------------------------
>     [mpjohn <at> oc1757000783 myJavaStuff]$ opreport
>     Using /home/mpjohn/myJavaStuff/oprofile_data/samples/ for samples directory.
>     CPU: Intel Sandy Bridge microarchitecture, speed 2401 MHz (estimated)
>     Counted CPU_CLK_UNHALTED events (Clock cycles when not halted) with a unit mask of 0x00 (No unit mask)
count 100000
>     CPU_CLK_UNHALT...|
>       samples|      %|
>     ------------------
>        140438 100.000 java
>             CPU_CLK_UNHALT...|
>               samples|      %|
>             ------------------
>                133294 94.9131 anon (tgid:11436 range:0x7fc4ed000000-0x7fc4ed26ffff)
>                  4387  3.1238 libjvm.so
>                  2301  1.6384 no-vmlinux
>                   211  0.1502 libc-2.12.so <http://libc-2.12.so>
>                    90  0.0641 libpthread-2.12.so <http://libpthread-2.12.so>
>                    66  0.0470 libzip.so
>                    43  0.0306 ld-2.12.so <http://ld-2.12.so>
>                    20  0.0142 [vdso] (tgid:11436 range:0x7fffae4ea000-0x7fffae4eafff)
>                    18  0.0128 [vsyscall] (tgid:11436 range:0xffffffffff600000-0xffffffffff600fff)
>                     5  0.0036 libjava.so
>                     1 7.1e-04 libnss_files-2.12.so <http://libnss_files-2.12.so>
>                     1 7.1e-04 libjli.so
>                     1 7.1e-04 libverify.so
> 
>     -------------------------------------------------------
> 
>     Note the "anon" samples.  The JVM's JIT compiler puts JITed code into anonymous memory mappings.  The
oprofile JIT support works on the assumption that samples from JITed code will be associated with those
anonymous memory mappings.  So, if after profiling LLVM without the oprofile JIT agent support, you are
not seeing any "anon" samples, that tells me that LLVM is not putting JITed code in anonymous memory
mappings, and oprofile's JIT support won't work for it.
> 
>     I have verified that oprofile's support for Java JITed code works fine on Ubuntu.  Does oprofile's support
for LLVM JITed code work on any other platform?
> 
>     -Maynard
>     >
>     > Oprofile seems to be getting the events OK, and counting them, but just not saving them as anon samples
when they are outside the DSOs.
>     >
>     > Has anyone else on the list been  using oprofile with a non-Java jit configuration?
>     >
>     >
>     >
>     >
>     > On Wed, Oct 15, 2014 at 6:53 PM, Maynard Johnson <maynardj <at> us.ibm.com <mailto:maynardj <at> us.ibm.com>
<mailto:maynardj <at> us.ibm.com <mailto:maynardj <at> us.ibm.com>>> wrote:
>     >
>     >     On 10/15/2014 04:25 PM, Maurice Marks wrote:
>     >     > I'm trying to profile  non Java Jit code  (using llvm's built in oprofile interface) on Ubuntu 14.04 using operf.
>     >     > I built the latest git version of oprofile just to be sure I'm up to date.
>     >     >
>     >     > What I see is that there are lots of jit samples counted, but rather than being attributed to anon or to
(hopefully) <pid>.jo they are
>     >     > counted against one of the .so files.
>     >     >
>     >     > Like this:
>     >     > CPU: Intel Haswell microarchitecture, speed 3498 MHz (estimated)
>     >     > Counted CPU_CLK_UNHALTED events (Clock cycles when not halted) with a unit mask of 0x00 (No unit mask)
count 100000
>     >     > CPU_CLK_UNHALT...|
>     >     >   samples|      %|
>     >     > ------------------
>     >     >     20792 100.000 lli
>     >     >     CPU_CLK_UNHALT...|
>     >     >       samples|      %|
>     >     >     ------------------
>     >     >         20634 99.2401 ld-2.19.so <http://ld-2.19.so> <http://ld-2.19.so> <http://ld-2.19.so>
>     >     >            86  0.4136 no-vmlinux
>     >     >            27  0.1299 libLLVMCore.so
>     >     >            16  0.0770 libLLVMCodeGen.so
>     >     >            10  0.0481 libLLVMSelectionDAG.so
>     >     >             4  0.0192 libLLVMSupport.so
>     >     >             3  0.0144 libLLVMJIT.so
>     >     >             3  0.0144 libLLVMX86Desc.so
>     >     >             2  0.0096 libLLVMScalarOpts.so
>     >     >             2  0.0096 libLLVMX86CodeGen.so
>     >     >             1  0.0048 lli
>     >     >             1  0.0048 libc-2.19.so <http://libc-2.19.so> <http://libc-2.19.so> <http://libc-2.19.so>
>     >     >             1  0.0048 libpthread-2.19.so <http://libpthread-2.19.so> <http://libpthread-2.19.so> <http://libpthread-2.19.so>
>     >     >             1  0.0048 libLLVMAnalysis.so
>     >     >             1  0.0048 libLLVMAsmParser.so
>     >     >
>     >     > ~99% of the samples are actually in the Jit'd code, not in ld-2.19.so <http://ld-2.19.so>
<http://ld-2.19.so> <http://ld-2.19.so>.
>     >     >
>     >     > Debugging I see that the opjitagent calls are being made correctly for the jit'd routines, and jitdump
files are being generated.
>     >     > And opjitconv runs and deletes the jitdump files at the end. But because there are no "anon" samples
>     >     > nothing is reported.
>     >     >
>     >     > With-Vdebug in operf I see:
>     >     > ....
>     >     > profiled app ended normally.
>     >     > operf recording finished.
>     >     > Total bytes recorded from perf events: 841464
>     >     > operf-record process returned OK
>     >     > * * * * WARNING: Profiling rate was throttled back by the kernel * * * *
>     >     > The number of samples actually recorded is less than expected, but is
>     >     > probably still statistically valid.  Decreasing the sampling rate is the
>     >     > best option if you want to avoid throttling.
>     >     > operf_read: Total bytes received from operf_record process: 841280
>     >     > Calling _do_jitdump_convert
>     >     > start time/end time is 1413408126/1413408137
>     >     > opjitconv: Ending with rc = 2. This code is usually OK, but can be useful for debugging purposes.
>     >     > JIT dump processing complete.
>     >     > operf-read process returned OK
>     >     >
>     >     >
>     >     > I'm probably doing something wrong. But I'm not sure what.
>     >     > Any ideas?
>     >     Hi, Maurice.  Cool, I didn't know that LLVM had an interface to oprofile's JIT support. Googling, I see
that this have been around for a while.  So, the first question is have you ever gotten this to work
(yourself) in the past?  If so, then please provide details (distro, oprofile version, processor type, etc.).
>     >
>     >     What really jumps out at me is that according to the opjitconv start time/end time debug message above,
your profile run was 11 seconds, but you only got a total of 20792, while sampling at a rate of one sample per
100,000 CPU_CLK_UNHALTED events! I've never seen the kernel do throttling like that. There may be a
kernel issue there, but the first thing I would try is back off on the sampling rate ... try something like
one sample every 500,000 CPU_CLK_UNHALTED events.
>     >
>     >     -Maynard
>     >     >
>     >     >
>     >     >
>     >     >
>     >     >
>     >     > ------------------------------------------------------------------------------
>     >     > Comprehensive Server Monitoring with Site24x7.
>     >     > Monitor 10 servers for $9/Month.
>     >     > Get alerted through email, SMS, voice calls or mobile push notifications.
>     >     > Take corrective actions from your mobile device.
>     >     > http://p.sf.net/sfu/Zoho
>     >     >
>     >     >
>     >     >
>     >     > _______________________________________________
>     >     > oprofile-list mailing list
>     >     > oprofile-list <at> lists.sourceforge.net <mailto:oprofile-list <at> lists.sourceforge.net>
<mailto:oprofile-list <at> lists.sourceforge.net <mailto:oprofile-list <at> lists.sourceforge.net>>
>     >     > https://lists.sourceforge.net/lists/listinfo/oprofile-list
>     >     >
>     >
>     >
>     >
>     >
>     > --
>     > Not sent from my Blackberry, Raspberry or Gooseberry!
>     >
>     >
>     > ------------------------------------------------------------------------------
>     > Comprehensive Server Monitoring with Site24x7.
>     > Monitor 10 servers for $9/Month.
>     > Get alerted through email, SMS, voice calls or mobile push notifications.
>     > Take corrective actions from your mobile device.
>     > http://p.sf.net/sfu/Zoho
>     >
>     >
>     >
>     > _______________________________________________
>     > oprofile-list mailing list
>     > oprofile-list <at> lists.sourceforge.net <mailto:oprofile-list <at> lists.sourceforge.net>
>     > https://lists.sourceforge.net/lists/listinfo/oprofile-list
>     >
> 
> 
> 
> 
> -- 
> Not sent from my Blackberry, Raspberry or Gooseberry!

------------------------------------------------------------------------------
Comprehensive Server Monitoring with Site24x7.
Monitor 10 servers for $9/Month.
Get alerted through email, SMS, voice calls or mobile push notifications.
Take corrective actions from your mobile device.
http://p.sf.net/sfu/Zoho
Maurice Marks | 15 Oct 23:25 2014
Picon

operf jit problem. No anon samples?

I'm trying to profile  non Java Jit code  (using llvm's built in oprofile interface) on Ubuntu 14.04 using operf.
I built the latest git version of oprofile just to be sure I'm up to date.

What I see is that there are lots of jit samples counted, but rather than being attributed to anon or to (hopefully) <pid>.jo they are
counted against one of the .so files.

Like this:
CPU: Intel Haswell microarchitecture, speed 3498 MHz (estimated)
Counted CPU_CLK_UNHALTED events (Clock cycles when not halted) with a unit mask of 0x00 (No unit mask) count 100000
CPU_CLK_UNHALT...|
  samples|      %|
------------------
    20792 100.000 lli
    CPU_CLK_UNHALT...|
      samples|      %|
    ------------------
        20634 99.2401 ld-2.19.so
           86  0.4136 no-vmlinux
           27  0.1299 libLLVMCore.so
           16  0.0770 libLLVMCodeGen.so
           10  0.0481 libLLVMSelectionDAG.so
            4  0.0192 libLLVMSupport.so
            3  0.0144 libLLVMJIT.so
            3  0.0144 libLLVMX86Desc.so
            2  0.0096 libLLVMScalarOpts.so
            2  0.0096 libLLVMX86CodeGen.so
            1  0.0048 lli
            1  0.0048 libc-2.19.so
            1  0.0048 libpthread-2.19.so
            1  0.0048 libLLVMAnalysis.so
            1  0.0048 libLLVMAsmParser.so

~99% of the samples are actually in the Jit'd code, not in ld-2.19.so.

Debugging I see that the opjitagent calls are being made correctly for the jit'd routines, and jitdump files are being generated.
And opjitconv runs and deletes the jitdump files at the end. But because there are no "anon" samples
nothing is reported.

With-Vdebug in operf I see:
....
profiled app ended normally.
operf recording finished.
Total bytes recorded from perf events: 841464
operf-record process returned OK
* * * * WARNING: Profiling rate was throttled back by the kernel * * * *
The number of samples actually recorded is less than expected, but is
probably still statistically valid.  Decreasing the sampling rate is the
best option if you want to avoid throttling.
operf_read: Total bytes received from operf_record process: 841280
Calling _do_jitdump_convert
start time/end time is 1413408126/1413408137
opjitconv: Ending with rc = 2. This code is usually OK, but can be useful for debugging purposes.
JIT dump processing complete.
operf-read process returned OK


I'm probably doing something wrong. But I'm not sure what.
Any ideas?



------------------------------------------------------------------------------
Comprehensive Server Monitoring with Site24x7.
Monitor 10 servers for $9/Month.
Get alerted through email, SMS, voice calls or mobile push notifications.
Take corrective actions from your mobile device.
http://p.sf.net/sfu/Zoho
_______________________________________________
oprofile-list mailing list
oprofile-list <at> lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oprofile-list
Carl Love | 9 Oct 20:43 2014
Picon

Re: [PATCH] Fix configure script to error out when no perf_events support is found

Maynard:

I tested on a Power7 with Red Hat Enterprise Linux Server release 6.5
(Santiago).  I tried installing the patch on a fresh git pull.  The
patch applied cleanly.  

I ran autogen.sh and configure to install locally in my directory.  That
all worked as expected.  I did a test run of operf and ocount to make
sure they built correctly.

I then tweeked the minimum version number, variables/directory location
names. in the script.  I tried to make it "appear" as if the needed
version and the expected files were not there to get the script to fail.
It seemed to fail as expected for each case I was testing.  The
resultant error message was consistent with the expected failure.  

I didn't find any formatting issues.

As far as I can tell, it looks good.

                     Carl Love

On Mon, 2014-10-06 at 16:47 -0500, Maynard Johnson wrote:
> Fix configure script to error out when no perf_events support is found
> 
> Prior to release 1.0.0, if the configure script found that the kernel
> version was not new enough to have perf_events support or if the perf_event.h
> header file could not be found, we would just fall back to building only
> the legacy opcontrol-based profiler and would skip building operf and ocount.
> But as of release 1.0.0, the opcontrol-based profiler is no longer included,
> so if operf and ocount cannot be built, we should error out of the configure
> execution, which is what this patch does.
> 
> Signed-off-by: Maynard Johnson <maynardj <at> us.ibm.com>
> ---
>  configure.ac |  149 +++++++++++++++++++++++++++++-----------------------------
>  1 files changed, 74 insertions(+), 75 deletions(-)
> 
> Index: op-master/configure.ac
> ===================================================================
> --- op-master.orig/configure.ac
> +++ op-master/configure.ac
>  <at>  <at>  -57,7 +57,7  <at>  <at>  AC_PROG_CC
>  AC_PROG_CPP
>  AC_PROG_CXX
>  AC_CHECK_PROG(LD,ld,ld,)
> -test "$LD" || AC_ERROR(ld not found)
> +test "$LD" || AC_MSG_ERROR(ld not found)
> 
>  # --with-kernel for cross compilation
>  AC_ARG_WITH(kernel,
>  <at>  <at>  -80,8 +80,6  <at>  <at>  if test "$KERNELDIR" != ""; then
>  		PERF_EVENT_FLAGS=" -I$KERNELDIR/include"
>  		AC_SUBST(PERF_EVENT_FLAGS)
>  		PERF_EVENT_H="$KERNELDIR/include/linux/perf_event.h"
> -	else
> -		echo "$KERNELDIR does not exist."
>  	fi
>  else
>  	PERF_EVENT_H="/usr/include/linux/perf_event.h"
>  <at>  <at>  -92,6 +90,10  <at>  <at>  kernel_may_have_perf_events_support="no"
>  AX_KERNEL_VERSION(2, 6, 31, <=, kernel_may_have_perf_events_support="yes",
>  kernel_has_perf_events_support="no")
> 
> +if test "$kernel_has_perf_events_support" = "no"; then
> +	AC_MSG_ERROR(Your kernel version is older than the required level (2.6.31) to build oprofile.)
> +fi
> +
>  dnl The AX_KERNEL_VERSION macro may return kernel_may_have_perf_events_support="yes",
>  dnl indicating a partial answer.  Some architectures do not implement the Performance
>  dnl Events Kernel Subsystem even with kernel versions > 2.6.31 -- i.e., not even
>  <at>  <at>  -135,66 +137,84  <at>  <at>  else
>  	kernel_has_perf_events_support="no"
>  fi
> 
> -AM_CONDITIONAL(BUILD_FOR_PERF_EVENT, test "$kernel_has_perf_events_support" = "yes")
> -
> -if test "$kernel_has_perf_events_support" = "yes"; then
> -	HAVE_PERF_EVENTS='1'
> -	AC_MSG_CHECKING([whether PERF_RECORD_MISC_GUEST_KERNEL is defined in perf_event.h])
> -	rm -f test-for-PERF_GUEST
> -	AC_LANG_CONFTEST(
> -		[AC_LANG_PROGRAM([[#include <linux/perf_event.h>]],
> -			[[unsigned int pr_guest_kern = PERF_RECORD_MISC_GUEST_KERNEL;
> -			unsigned int pr_guest_user = PERF_RECORD_MISC_GUEST_USER;]])
> -		])
> -	$CC conftest.$ac_ext $CFLAGS $LDFLAGS $LIBS $PERF_EVENT_FLAGS -o test-for-PERF_GUEST  > /dev/null 2>&1
> -	if test -f test-for-PERF_GUEST; then
> -		echo "yes"
> -		HAVE_PERF_GUEST_MACROS='1'
> +if test "$kernel_has_perf_events_support" != "yes"; then
> +	if test "$KERNELDIR" != ""; then
> +		echo "ERROR: You requested to build oprofile with '--with-kernel=$KERNELDIR',"
> +		if ! test -d $KERNELDIR; then
> +			echo "but that directory does not exist."
> +		elif test "$PERF_EVENT_H_EXISTS" != "yes"; then
> +			echo "but headers were not accessible at the given location."
> +			echo "Be sure you have run the following command from within your kernel source tree:"
> +			echo "     make headers_install INSTALL_HDR_PATH=<kernel-hdrs-install-dir>"
> +			echo "Then pass <kernel-hdrs-install-dir> to oprofile's '--with-kernel' configure option."
> +		else
> +			echo "but your kernel does not appear to have the necessary support to run oprofile."
> +		fi
>  	else
> -		echo "no"
> -		HAVE_PERF_GUEST_MACROS='0'
> +		if test "$PERF_EVENT_H_EXISTS" != "yes"; then
> +			echo "Error: perf_event.h not found.  Either install the kernel headers package or"
> +			echo "use the --with-kernel option."
> +		else
> +			echo "Error: Your kernel does not appear to have the necessary support to run oprofile."
> +		fi
>  	fi
> -	AC_DEFINE_UNQUOTED(HAVE_PERF_GUEST_MACROS, $HAVE_PERF_GUEST_MACROS,
[PERF_RECORD_MISC_GUEST_KERNEL is defined in perf_event.h])
> -	rm -f test-for-PERF_GUEST*
> +	AC_MSG_ERROR(Unable to build oprofile. Exiting.)
> +fi
> 
> -	AC_MSG_CHECKING([whether precise_ip is defined in perf_event.h])
> -	rm -f test-for-precise-ip
> -	AC_LANG_CONFTEST(
> -		[AC_LANG_PROGRAM([[#include <linux/perf_event.h>]],
> -			[[struct perf_event_attr attr;
> -			attr.precise_ip = 2;]])
> -		])
> -	$CC conftest.$ac_ext $CFLAGS $LDFLAGS $LIBS $PERF_EVENT_FLAGS -o test-for-precise-ip  > /dev/null 2>&1
> -	if test -f test-for-precise-ip; then
> -		echo "yes"
> -		HAVE_PERF_PRECISE_IP='1'
> -	else
> -		echo "no"
> -		HAVE_PERF_PRECISE_IP='0'
> -	fi
> -	AC_DEFINE_UNQUOTED(HAVE_PERF_PRECISE_IP, $HAVE_PERF_PRECISE_IP, [precise_ip is defined in perf_event.h])
> -	rm -f test-for-precise-ip*
> +AM_CONDITIONAL(BUILD_FOR_PERF_EVENT, test "$kernel_has_perf_events_support" = "yes")
> 
> +
> +HAVE_PERF_EVENTS='1'
> +AC_MSG_CHECKING([whether PERF_RECORD_MISC_GUEST_KERNEL is defined in perf_event.h])
> +rm -f test-for-PERF_GUEST
> +AC_LANG_CONFTEST(
> +	[AC_LANG_PROGRAM([[#include <linux/perf_event.h>]],
> +		[[unsigned int pr_guest_kern = PERF_RECORD_MISC_GUEST_KERNEL;
> +		unsigned int pr_guest_user = PERF_RECORD_MISC_GUEST_USER;]])
> +	])
> +$CC conftest.$ac_ext $CFLAGS $LDFLAGS $LIBS $PERF_EVENT_FLAGS -o test-for-PERF_GUEST  > /dev/null 2>&1
> +if test -f test-for-PERF_GUEST; then
> +	echo "yes"
> +	HAVE_PERF_GUEST_MACROS='1'
>  else
> -	HAVE_PERF_EVENTS='0'
> -	AC_MSG_RESULT([No perf_events support available; falling back to legacy oprofile])
> +	echo "no"
> +	HAVE_PERF_GUEST_MACROS='0'
>  fi
> +AC_DEFINE_UNQUOTED(HAVE_PERF_GUEST_MACROS, $HAVE_PERF_GUEST_MACROS,
[PERF_RECORD_MISC_GUEST_KERNEL is defined in perf_event.h])
> +rm -f test-for-PERF_GUEST*
> +
> +AC_MSG_CHECKING([whether precise_ip is defined in perf_event.h])
> +rm -f test-for-precise-ip
> +AC_LANG_CONFTEST(
> +	[AC_LANG_PROGRAM([[#include <linux/perf_event.h>]],
> +		[[struct perf_event_attr attr;
> +		attr.precise_ip = 2;]])
> +	])
> +$CC conftest.$ac_ext $CFLAGS $LDFLAGS $LIBS $PERF_EVENT_FLAGS -o test-for-precise-ip  > /dev/null 2>&1
> +if test -f test-for-precise-ip; then
> +	echo "yes"
> +	HAVE_PERF_PRECISE_IP='1'
> +else
> +	echo "no"
> +	HAVE_PERF_PRECISE_IP='0'
> +fi
> +AC_DEFINE_UNQUOTED(HAVE_PERF_PRECISE_IP, $HAVE_PERF_PRECISE_IP, [precise_ip is defined in perf_event.h])
> +rm -f test-for-precise-ip*
> +
> 
>  AC_DEFINE_UNQUOTED(HAVE_PERF_EVENTS, $HAVE_PERF_EVENTS, [Kernel support for perf_events exists])
>  AC_CANONICAL_HOST
> -if test "$HAVE_PERF_EVENTS" = "1"; then
> -	PFM_LIB=
> -	if test "$host_cpu" = "powerpc64le" -o "$host_cpu" = "powerpc64"; then
> -		AC_CHECK_HEADER(perfmon/pfmlib.h,,[AC_MSG_ERROR([pfmlib.h not found; may be provided by
libpfm devel or papi devel package])])
> -		AC_CHECK_LIB(pfm,pfm_get_os_event_encoding, HAVE_LIBPFM3='0'; HAVE_LIBPFM='1', [
> -			AC_CHECK_LIB(pfm, pfm_get_event_name, HAVE_LIBPFM3='1'; HAVE_LIBPFM='1',
> -			[AC_MSG_ERROR([libpfm not found; may be provided by libpfm devel or papi devel package])])])
> -		PFM_LIB="-lpfm"
> -		AC_DEFINE_UNQUOTED(HAVE_LIBPFM3, $HAVE_LIBPFM3, [Define to 1 if using libpfm3; 0 if using newer libpfm])
> -		AC_DEFINE_UNQUOTED(HAVE_LIBPFM, $HAVE_LIBPFM, [Define to 1 if libpfm is available])
> -	fi
> -	AC_SUBST(PFM_LIB)
> +PFM_LIB=
> +if test "$host_cpu" = "powerpc64le" -o "$host_cpu" = "powerpc64"; then
> +	AC_CHECK_HEADER(perfmon/pfmlib.h,,[AC_MSG_ERROR([pfmlib.h not found; may be provided by libpfm
devel or papi devel package])])
> +	AC_CHECK_LIB(pfm,pfm_get_os_event_encoding, HAVE_LIBPFM3='0'; HAVE_LIBPFM='1', [
> +		AC_CHECK_LIB(pfm, pfm_get_event_name, HAVE_LIBPFM3='1'; HAVE_LIBPFM='1',
> +		[AC_MSG_ERROR([libpfm not found; may be provided by libpfm devel or papi devel package])])])
> +	PFM_LIB="-lpfm"
> +	AC_DEFINE_UNQUOTED(HAVE_LIBPFM3, $HAVE_LIBPFM3, [Define to 1 if using libpfm3; 0 if using newer libpfm])
> +	AC_DEFINE_UNQUOTED(HAVE_LIBPFM, $HAVE_LIBPFM, [Define to 1 if libpfm is available])
>  fi
> +AC_SUBST(PFM_LIB)
> 
>  AC_ARG_WITH(java,
>  [  --with-java=java-home        Path to Java home directory (default is "no"; "yes" will use /usr as Java home)],
>  <at>  <at>  -425,25 +445,3  <at>  <at>  elif test "`getent passwd oprofile 2>/de
>  		echo "         The 'oprofile' group must be the default group for the 'oprofile' user."
>  	fi
>  fi
> -
> -if  test "$PERF_EVENT_H_EXISTS" != "yes" && test "$kernel_may_have_perf_events_support" = "yes"; then
> -	echo "Warning: perf_event.h not found.  Either install the kernel headers package or"
> -	echo "use the --with-kernel option if you want the non-root, single application"
> -	echo "profiling support provided by operf."
> -	echo ""
> -	echo "If you run 'make' now, only the legacy ocontrol-based profiler will be built."
> -fi
> -
> -if test "$KERNELDIR" != "" && test "$kernel_has_perf_events_support" != "yes"; then
> -	if ! test -d $KERNELDIR; then
> -		echo "WARNING: You passed '--with-kernel=$KERNELDIR', but $KERNELDIR"
> -		echo "does not exist."
> -	else
> -		echo "Warning: You requested to build with the '--with-kernel' option, but your kernel"
> -		echo "headers were not accessible at the given location. Be sure you have run the following"
> -		echo "command from within your kernel source tree:"
> -		echo "     make headers_install INSTALL_HDR_PATH=<kernel-hdrs-install-dir>"
> -		echo "Then pass <kernel-hdrs-install-dir> to oprofile's '--with-kernel' configure option."
> -	fi
> -	echo ""
> -fi
> 
> 
> ------------------------------------------------------------------------------
> Slashdot TV.  Videos for Nerds.  Stuff that Matters.
> http://pubads.g.doubleclick.net/gampad/clk?id=160591471&iu=/4140/ostg.clktrk
> _______________________________________________
> oprofile-list mailing list
> oprofile-list <at> lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/oprofile-list
> 

------------------------------------------------------------------------------
Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
http://pubads.g.doubleclick.net/gampad/clk?id=154622311&iu=/4140/ostg.clktrk

Gmane