Tidy powerpc64 bfd target check

Testing for a bfd_target vector might (will!) break.  See
https://sourceware.org/ml/binutils/2014-04/msg00283.html

It's safer to ask BFD for the target name.  I left the direct target
vector checks in configure tests, and updated them, even though the
target vector is no longer used in oprofile code, because a run-time
configure test for powerpc64 support in bfd:
       #include <bfd.h>
       int main(void)
       { return !bfd_find_target("elf64-powerpc", (void *)0); }
unfortunately isn't possible when cross-compiling.

The bfd_target vector tests could be omitted if we aren't bothered by
the small runtime overhead of a strncmp on targets other than
powerpc64.

        * libutil++/bfd_support.cpp (get_synth_symbols): Don't check for
        ppc64 target vector, use bfd_get_target to return the target
        name instead.
        * m4/binutils.m4: Modernize bfd_get_synthetic_symtab checks to
        use AC_LINK_IFELSE.  Check for either powerpc_elf64_vec or
        bfd_elf64_powerpc_vec.

Signed-off-by: Alan Modra <amodra@gmail.com>
configure: fix test-for-synth check with GCC 4.9.0

With GCC 4.9.0 oprofile 0.9.9 build fails on non-PPC platfroms because
the "test-for-synth" configure check result is incorrect: There is a NULL
pointer dereference in the test program, so the compiler seems to optimize
the rest of the code away, and the test will always succeed regardless
whether powerpc_elf64_vec/bfd_elf64_powerpc_vec are present or not.
Fix by allocating the referred struct statically.

While at it, also include stdio.h to avoid a compiler warning.

Signed-off-by: Aaro Koskinen <aaro.koskinen@iki.fi>
Send 'Unable to obtain appname' message to stdout

In operf_process_info::set_appname, we look at /proc/<PID>/exe
to see if we can obtain the process's appname.  However, the
process may have already ended, in which case we print the message

  "Unable to obtain appname from /proc/<PID>/exe"

This error message should *NOT* be sent to stderr, but instead,
should go to stdout so that it's not seen on the screen when doing:
    operf --verbose=all <cmd>   > out-file

Signed-off-by: Maynard Johnson <maynardj@us.ibm.com>
Change user guide to clarify callgraph is not supported for JIT samples

Signed-off-by: Maynard Johnson <maynardj@us.ibm.com>
Bug #266: exclude/include files option doesn't work for opannotate -a

The opannotate man page did not make it clear at all that the --exclude-file
and --include-file options apply *only* when specifying "--source"
annotation.  This patch updates the man page to clarify the behavior.
It also adds a check in opannotate to disallow specifying either of these
options when "--assembly" is specified.

Signed-off-by: Maynard Johnson <maynardj@us.ibm.com>
operf log may over-report "sample address not in expected range for domain"

When find_mapping_for_sample() is called, only the sample address is passed.
However, in certain situations, the address alone is not enough to find the
proper matching operf_mmap object.  For example, hypervisor addresses can
overlap with userspace addresses where the vdso gets mapped in a 32-bit
process on the ppc64 architecture.  If an operf_mmap object has already been
created with a particular memory address range and then a sample address
from VDSO in a 32-bit process needs to be processed, we may incorrectly match
that address with the hypervisor operf_mmap object.  With this patch, we now
will pass a flag ('hypervisor_sample') and ensure that we only return an
operf_mmap object if the address is a match AND the flag value matches with
operf_mmap.is_hypervisor.

Signed-off-by: Maynard Johnson <maynardj@us.ibm.com>
Minor error-handling fixes needed for ocount

The main fix in this patch is to properly handle the case
where perf_event_open fails after we have already started
the app for which the user requested to count events.
Prior to this fix, ocount would simply exit, leaving the
app to run to completion.  This patch causes ocount
to kill the app if we encounter a perf_event_open error.

Signed-off-by: Maynard Johnson <maynardj@us.ibm.com>
Update events for IBM POWER8 processor

The initial support for the IBM POWER8 processor was added to oprofile in
May 2013. Some events were held back as their descriptions may have exposed
information about the POWER8 architecture that IBM wanted to remain private
until the official announcement. Some other events were held back because they
had not yet been verified. The POWER8 has now been announced and all events
have been verified, so we can now publish all events.

Signed-off-by: Maynard Johnson <maynardj@us.ibm.com>
opreport XML: binary-level count field issues

See oprofile bug # 236 (https://sourceforge.net/p/oprofile/bugs/236/).

There are several issues relating to the use of the 'count' element
defined in opreport.xsd. For example, below is the current schema
definition for the 'binary' element.  Note the usage of the 'count'
element:

<xs:element name="binary">
<xs:complexType>
<xs:sequence>
<xs:element minOccurs="1" maxOccurs="1" ref="count"/>
<xs:element minOccurs="0" maxOccurs="unbounded" ref="symbol"/>
<!-- When the separate=lib option is used an binary
can contain a list of library Modules. -->
<xs:element minOccurs="0" maxOccurs="unbounded" ref="module"/>
</xs:sequence>
<xs:attribute name="name" type="xs:string" use="required"/>
</xs:complexType>
</xs:element>

There have been questions from users whether the 'count' element
associated with the 'binary' element is supposed to represent a
total count across all modules for the executable or if it is only
the count for the executable itself (the answer is the latter).

Additionally, it's possible that there may be no samples at all
for the binary file -- i.e., all samples collected were for module
elements -- thus, the minOccurs attribute for the 'count' element
of 'binary' should be '0'.

Finally, using xmllint on a XML instance document created from
opreport on a profile run that specified "--separate-cpu" identified
that the instance document was invalid when compared against its
associated schema file (opreport.xsd). Reviewing the schema, I
realized that all usages of the 'count' element were wrong insofar
as the maxOccurs attribute. Instead of being set to '1', maxOccurs
should be 'unbounded' since we can have multiple 'count' elements
associated with any given higher level element (e.g., 'binary')
if there are multiple classes in the profile.  Multiple classes
will exist for a profile for various reasons -- e.g., profiling with
'--separate-cpu', or multiple events.

This patch addresses these issues. The major version number of the
schema is not being changed -- only the minor number.  This is because
instance documents that previously validated using the old schema
will still be valid with the new schema.

A testsuite patch is being developed to validate XML instance documents
for various scenarios.

Signed-off-by: Maynard Johnson <maynardj@us.ibm.com>
opreport: header timestamps are different for kallsyms file

The time stamp for kallsyms can be different because it is not a real
file.  Hence, when there are samples from the kallsyms file and the
following conditions are met you get an error about the time stamps
not matching.

  - operf was run with the '--separate-thread' option
  - operf was run either as root or as normal user where
    /proc/sys/kernel/kptr_restrict is set to 0
  - The application being profiled is a multi-threaded app that
    executes both pthread_create and fork[2]

This patch fixes the issue by assigning the time stamp of zero when
the source file is kallsyms.

Signed-off-by: Carl Love <cel@us.ibm.com>
Fix sample data pipe partial read handling

Unless the user specifies the "--lazy-conversion" option with operf,
there will be separate "record" and "convert" processes started
by operf. The record process reads the sample data from the kernel
(via mmap'ed memory) and sends that data to the convert process
over a pipe. The convert process takes the raw sample data
and converts it to oprofile sample files. In the procedure for
reading the pipe, the convert process does two reads: one read to
obtain the sample data event header (which will give the size of
the whole sample data event), and a second read to get the rest
of the event record. For both of these reads, there is code to handle
return values that imply something other than a successful read of the
record. If the value returned is > 0 but less than the expected
length, we go back and do the read *again* to get the rest of the
record. However, in the second read (to obtain the bulk of the event
record), we were doing a "goto" to the wrong place -- we were going
back to the location of the first read.

This problem, in actual practice, is not likely to occur, since the
record process should normally be able to write an entire event
record to the pipe wihout interruption. But if it does occur, the
convert process will probably fail with a message like the following:

Event num -1 for id <x> is invalid. Sample data appears to be corrupted.

In fact, about a year ago, a user had reported such a problem. It was
intermittent, and was not reproducible except on that user's particular
system, which was a very large server system. He was doing a system-wide
profile of a Java benchmark. By lowering the sampling rate, the problem
went away. At the time, I was not able to find the problem, but I suspect
that the problem described above that's addressed by this patch is very
likely the cause of his problem, too. I've contacted this user, but so
far, he's not been able to reproduce the original problem in order to
effectively test this patch. Nevertheless, I'm confident that this fix
is a correct one and should be done.

Signed-off-by: Maynard Johnson <maynardj@us.ibm.com>
Remove unused functions causing errors in recent gcc

The Fedora rawhide compiler is now stricter and will treat the
warnings for unused functions as errors and stop the compile. This patch
removes two unused functions in the code.

Signed-off-by: William Cohen <wcohen@redhat.com>
Fix vsyscall sample collection on x86 architectures

On certain architectures running older kernels (x86* on kernel 3.0 and older, I think),
a static mapping is  placed into every process's memory map to provide vsyscall
functionality. This mapping is labeled '[vsyscall]'. This mapping is a mechanism
for reducing latency of a handful of calls (e.g., gettimeofday) that would otherwise
require a more expensive system call.

When operf is used to collect a profile on an application that uses vsyscall functions,
the samples taken within the vsyscall mapping are lost. For example, profiling the
program below [1] would result in a "Lost samples detected" message from operf, and the
operf.log would show something like the following:

-- OProfile/operf Statistics --
Nr. non-backtrace samples: 71964
Nr. kernel samples: 203
Nr. user space samples: 71761
Nr. samples lost due to sample address not in expected range for domain: 0
Nr. lost kernel samples: 0
Nr. samples lost due to sample file open failure: 0
Nr. samples lost due to no permanent mapping: 63590
                                              ^-- BAD!!
For some reason (which I don't care to investigate since vsyscall is now replaced
by vDSO), the kernel's perf_events subsystem does not send a PERF_RECORD_MMAP
message for this mapping.  This patch adds a function to synthesize such a
message so that samples taken in the vsyscall memory range can be correctly
attributed. Note that when using operf with "--pid" or "--system-wide", this new
function need not be called since when either of those two options are used, operf
already manually generates PERF_RECORD_MMAP messages for all memory mappings for
the process(es) being profiled.  However, a fix was needed in that area of operf
to recognize the '[vsyscall]' label and to create the corresponding PERF_RECORD_MMAP
for it.

[1]
  ------------------

int main(void)
{
        struct  timeval time;
        int     rc;
        while (1)
               rc = gettimeofday(&time, NULL);

        return rc;
}
-------------------

Signed-off-by: Maynard Johnson <maynardj@us.ibm.com>