There's no reason to keep it in separate directory now when we moved out
the rest of the files.
Signed-off-by: NJiri Olsa <jolsa@kernel.org>
Cc: David Ahern <dsahern@gmail.com>
Cc: Namhyung Kim <namhyung@kernel.org>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Link: http://lkml.kernel.org/r/1470074555-24889-6-git-send-email-jolsa@kernel.orgSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>

Automatically test the bitmap_scnprintf function.
Signed-off-by: NJiri Olsa <jolsa@kernel.org>
Tested-by: NArnaldo Carvalho de Melo <acme@redhat.com>
Cc: David Ahern <dsahern@gmail.com>
Cc: Namhyung Kim <namhyung@kernel.org>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Link: http://lkml.kernel.org/r/1470074555-24889-5-git-send-email-jolsa@kernel.orgSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>

Add support to perform logical and on bitmaps.  Code taken from kernel's
include/linux/bitmap.h.
Signed-off-by: NJiri Olsa <jolsa@kernel.org>
Cc: David Ahern <dsahern@gmail.com>
Cc: Namhyung Kim <namhyung@kernel.org>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Link: http://lkml.kernel.org/r/1470074555-24889-4-git-send-email-jolsa@kernel.orgSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>

Add support to print bitmap list. Code mostly taken from kernel's
bitmap_list_string.
Signed-off-by: NJiri Olsa <jolsa@kernel.org>
Cc: David Ahern <dsahern@gmail.com>
Cc: Namhyung Kim <namhyung@kernel.org>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Link: http://lkml.kernel.org/r/1470074555-24889-3-git-send-email-jolsa@kernel.org
[ s/bitmap_snprintf/bitmap_scnprintf/g as it is a scnprintf wrapper, having the same semantics wrt return value ]
Signed-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>

Adding bitmap_alloc function to dynamically allocate bitmap.
Signed-off-by: NJiri Olsa <jolsa@kernel.org>
Cc: David Ahern <dsahern@gmail.com>
Cc: Jiri Olsa <jolsa@kernel.org>
Cc: Namhyung Kim <namhyung@kernel.org>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Link: http://lkml.kernel.org/r/20160802113302.GA7479@kravaSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>

Signed-off-by: NNamhyung Kim <namhyung@kernel.org>
Cc: David Ahern <dsahern@gmail.com>
Cc: Jiri Olsa <jolsa@kernel.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Steven Rostedt <rostedt@goodmis.org>
Link: http://lkml.kernel.org/r/20160802050148.3413-1-namhyung@kernel.orgSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>

On my Archlinux machine, perf faild to build like below:

    CC       scripts/perl/Perf-Trace-Util/Context.o
  In file included from /usr/lib/perl5/core/perl/CORE/perl.h:3905:0,
                   from Context.xs:23:
  /usr/lib/perl5/core/perl/CORE/inline.h: In function :
  /usr/lib/perl5/core/perl/CORE/cop.h:612:13: warning: declaration of 'av'
                                  shadows a previous local [-Werror-shadow]
             AV *av =3D GvAV(PL_defgv);
                 ^
  /usr/lib/perl5/core/perl/CORE/inline.h:526:5: note: in expansion of
                                  macro 'CX_POP_SAVEARRAY'
         CX_POP_SAVEARRAY(cx);
         ^~~~~~~~~~~~~~~~
  In file included from /usr/lib/perl5/core/perl/CORE/perl.h:5853:0,
                   from Context.xs:23:
  /usr/lib/perl5/core/perl/CORE/inline.h:518:9: note:
                                  shadowed declaration is here
         AV *av;
             ^~

What I did to fix is adding '-Wno-shadow' as the error message said it's
the cause of the failure.  Since it's from the perl (not perf) code
base, we don't have the control so I just wanted to ignore the warning
when compiling perl scripting code.

Committer note:

This also fixes the build on Fedora Rawhide.
Signed-off-by: NNamhyung Kim <namhyung@kernel.org>
Tested-by: NArnaldo Carvalho de Melo <acme@redhat.com>
Cc: Jiri Olsa <jolsa@kernel.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Link: http://lkml.kernel.org/r/20160802024317.31725-1-namhyung@kernel.orgSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>

If dso__build_id_filename(..., NULL, ...) returns !NULL its because it
allocated it, so, when reaching the  'if (dso__is_kcore()) test, we
already checked that and were just "fallbacking" to using
dso->long_name, but without freeing filename, thus leaking it.

Fix it by adding the dso__is_kcore() test to the 'or' group just after
it, the one containing the full fallback code, including freeing the
filename.

Cc: Adrian Hunter <adrian.hunter@intel.com>
Cc: David Ahern <dsahern@gmail.com>
Cc: Jiri Olsa <jolsa@kernel.org>
Cc: Namhyung Kim <namhyung@kernel.org>
Cc: Wang Nan <wangnan0@huawei.com>
Fixes: ee205503 ("perf tools: Fix annotation with kcore")
Link: http://lkml.kernel.org/n/tip-qi4rpjq8yo6myvg99kkgt0xz@git.kernel.orgSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>

We were just using pr_error() which makes it difficult for non stdio UIs
to provide errors using its widgets, as they need to somehow catch what
was passed to pr_error().

Fix it by introducing a __strerror() interface like the ones used
elsewhere, for instance target__strerror().

This is just the initial step, more work will be done, but first some
error handling bugs noticed while working on this need to be dealt with.

Cc: Adrian Hunter <adrian.hunter@intel.com>
Cc: David Ahern <dsahern@gmail.com>
Cc: Jiri Olsa <jolsa@kernel.org>
Cc: Namhyung Kim <namhyung@kernel.org>
Cc: Wang Nan <wangnan0@huawei.com>
Link: http://lkml.kernel.org/n/tip-dgd22zl2xg7x4vcnoa83jxfb@git.kernel.orgSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>

This function will not annotate anything, it will just disassembly the
given map->dso and symbol.

It currently does this by parsing the output of 'objdump --disassemble',
but this could conceivably be done using a library or an offshot of
the kernel's instruction decoder (arch/x86/lib/inat.c), etc.

Cc: Adrian Hunter <adrian.hunter@intel.com>
Cc: David Ahern <dsahern@gmail.com>
Cc: Jiri Olsa <jolsa@kernel.org>
Cc: Namhyung Kim <namhyung@kernel.org>
Cc: Wang Nan <wangnan0@huawei.com>
Link: http://lkml.kernel.org/n/tip-2xpfl4bfnrd6x584b390qok7@git.kernel.orgSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>

So no need for checking if it uses the strerror_r() GNU variant error
reporting mechanism, i.e. if it returns a pointer to a immutable string
internal to glibc.

Cc: Adrian Hunter <adrian.hunter@intel.com>
Cc: David Ahern <dsahern@gmail.com>
Cc: Jiri Olsa <jolsa@kernel.org>
Cc: Namhyung Kim <namhyung@kernel.org>
Cc: Wang Nan <wangnan0@huawei.com>
Fixes: c8b5f2c9 ("tools: Introduce str_error_r()")
Link: http://lkml.kernel.org/n/tip-xr83cd4y4r3cn6tq6w4f59jb@git.kernel.orgSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>

We will need to redirect the stderr as well, so open code popen as
a starting point.

Cc: Adrian Hunter <adrian.hunter@intel.com>
Cc: David Ahern <dsahern@gmail.com>
Cc: Jiri Olsa <jolsa@kernel.org>
Cc: Namhyung Kim <namhyung@kernel.org>
Cc: Wang Nan <wangnan0@huawei.com>
Link: http://lkml.kernel.org/n/tip-k0zt9svg4bswiglem7ornts4@git.kernel.orgSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>

That is the default used when no events is specified in tools, separate
it so that simpler tools that need no evlist can use it directly.

Cc: Adrian Hunter <adrian.hunter@intel.com>
Cc: David Ahern <dsahern@gmail.com>
Cc: Jiri Olsa <jolsa@kernel.org>
Cc: Namhyung Kim <namhyung@kernel.org>
Cc: Wang Nan <wangnan0@huawei.com>
Link: http://lkml.kernel.org/n/tip-67mwuthscwroz88x9pswcqyv@git.kernel.orgSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>

Merge tag 'perf-core-for-mingo-20160725' of git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux into perf/core

Pull perf/core improvements and fixes from Arnaldo Carvalho de Melo:

- Add AVX-512 support to the instruction decoder, used by Intel PT,
  fix vcvtph2ps instruction decoding (Adrian Hunter)

- Make objtool and vdso2c use the right arch header search path
  (Stephen Rothwell, Josh Poimboeuf, Arnaldo Carvalho de Melo)
Signed-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
Signed-off-by: NIngo Molnar <mingo@kernel.org>

This reverts commit e083a21f.

Not needed at all, tools/perf/util/perf_regs.h, included via:

  #include "perf_regs.h"

Should have a definition for PERF_REGS_MAX, and since this is dependent
on HAVE_PERF_REGS_SUPPORT, fixes the build on powerpc, noticed by trying
to cross compile this from ubuntu16.04 with a locally build libz &
elfutils pair, since those are not available in multilib packages.

Cc: Jiri Olsa <jolsa@kernel.org>
Cc: Naveen N. Rao <naveen.n.rao@linux.vnet.ibm.com>
Cc: Stephane Eranian <eranian@google.com>
Cc: Sukadev Bhattiprolu <sukadev@linux.vnet.ibm.com>
Link: http://lkml.kernel.org/n/tip-0bv204s71t4wuw1l53b6fz79@git.kernel.orgSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>

To be clear: this is a ppc64le hosted, x86_64 target cross build.
Signed-off-by: NStephen Rothwell <sfr@canb.auug.org.au>
Acked-by: NAndy Lutomirski <luto@kernel.org>
Cc: H. Peter Anvin <hpa@zytor.com>
Cc: Josh Poimboeuf <jpoimboe@redhat.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Link: http://lkml.kernel.org/r/20160723150845.3af8e452@canb.auug.org.auSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>

The objtool build fails in a cross-compiled environment on a non-x86
host with "ARCH=x86_64":

  tools/objtool/objtool-in.o: In function `decode_instructions':
  tools/objtool/builtin-check.c:276: undefined reference to `arch_decode_instruction'

We could override the ARCH environment variable and change it back to
x86, similar to what the objtool Makefile was doing before; but it's
tricky to override environment variables consistently.

Instead, take a similar approach used by the Linux top-level Makefile
and introduce a SRCARCH Makefile variable which evaluates to "x86" when
ARCH is either "x86_64" or "x86".
Reported-by: NStephen Rothwell <sfr@canb.auug.org.au>
Signed-off-by: NJosh Poimboeuf <jpoimboe@redhat.com>
Cc: Andy Lutomirski <luto@amacapital.net>
Cc: H. Peter Anvin <hpa@zytor.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Thomas Gleixner <tglx@linutronix.de>
Link: http://lkml.kernel.org/r/20160722191920.ej62fnspnqurbaa7@trebleSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>

From a conversation with Josh:

From http://lkml.kernel.org/r/20160722034118.guckaniobf3f7czc@treble :

It needs to be compiled with the host (powerpc) compiler, but then it
needs to disassemble target (x86) files.

 ----

So use HOSTARCH instead of ARCH.

Cc: Adrian Hunter <adrian.hunter@intel.com>
Cc: David Ahern <dsahern@gmail.com>
Cc: Jiri Olsa <jolsa@kernel.org>
Cc: Josh Poimboeuf <jpoimboe@redhat.com>
Cc: Namhyung Kim <namhyung@kernel.org>
Cc: Stephen Rothwell <sfr@canb.auug.org.au>
Cc: Wang Nan <wangnan0@huawei.com>
Link: http://lkml.kernel.org/r/20160722034118.guckaniobf3f7czc@treble
Link: http://lkml.kernel.org/n/tip-le1m1yzxnfpt3msbblu40nm8@git.kernel.orgSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>

objtool's Makefile was setting up ARCH but fixing up just the x86_64 ->
x86, using Makefile.arch will do the necessary fixups for all arches.

Cc: Adrian Hunter <adrian.hunter@intel.com>
Cc: David Ahern <dsahern@gmail.com>
Cc: Jiri Olsa <jolsa@kernel.org>
Cc: Josh Poimboeuf <jpoimboe@redhat.com>
Cc: Namhyung Kim <namhyung@kernel.org>
Cc: Stephen Rothwell <sfr@canb.auug.org.au>
Cc: Wang Nan <wangnan0@huawei.com>
Link: http://lkml.kernel.org/n/tip-hbq0bbh03u2b722vozcyql31@git.kernel.orgSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>

For tools that needs to be always compiled with the host headers.

Cc: Adrian Hunter <adrian.hunter@intel.com>
Cc: David Ahern <dsahern@gmail.com>
Cc: Jiri Olsa <jolsa@kernel.org>
Cc: Josh Poimboeuf <jpoimboe@redhat.com>
Cc: Namhyung Kim <namhyung@kernel.org>
Cc: Stephen Rothwell <sfr@canb.auug.org.au>
Cc: Wang Nan <wangnan0@huawei.com>
Link: http://lkml.kernel.org/n/tip-907q32k2nep6q670dkxypmu6@git.kernel.orgSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>

Cross building it on Ubuntu 16.04 to ARM ends up showing we get
the free() prototype by luck in other environments, fix it.

Cc: Adrian Hunter <adrian.hunter@intel.com>
Cc: David Ahern <dsahern@gmail.com>
Cc: Jiri Olsa <jolsa@kernel.org>
Cc: Namhyung Kim <namhyung@kernel.org>
Cc: Wang Nan <wangnan0@huawei.com>
Link: http://lkml.kernel.org/n/tip-0ktfgmmyhcfw8ondka2013f3@git.kernel.orgSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>

Previous patches added support for Intel's AVX-512 instructions to the
kernel and perf tools instruction decoders.

AVX-512 instructions are documented in Intel Architecture Instruction
Set Extensions Programming Reference (February 2016).

Add a representative set of instructions to perf's "new instructions"
test. e.g.

	perf test "new instructions"

Or to view a particular instruction:

	perf test -v "new instructions" 2>&1 | grep vbroadcasti64x4
Signed-off-by: NAdrian Hunter <adrian.hunter@intel.com>
Acked-by: NIngo Molnar <mingo@kernel.org>
Acked-by: NMasami Hiramatsu <mhiramat@kernel.org>
Tested-by: NArnaldo Carvalho de Melo <acme@redhat.com>
Cc: Andy Lutomirski <luto@amacapital.net>
Cc: Dan Williams <dan.j.williams@intel.com>
Cc: H. Peter Anvin <hpa@zytor.com>
Cc: Jiri Olsa <jolsa@redhat.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: X86 ML <x86@kernel.org>
Link: http://lkml.kernel.org/r/1469003437-32706-5-git-send-email-adrian.hunter@intel.comSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>

Add support for Intel's AVX-512 instructions to perf tools instruction
decoder used by Intel PT.  The kernel's instruction decoder was updated in
a previous patch.

AVX-512 instructions are documented in Intel Architecture Instruction Set
Extensions Programming Reference (February 2016).

AVX-512 instructions are identified by a EVEX prefix which, for the purpose
of instruction decoding, can be treated as though it were a 4-byte VEX
prefix.

Existing instructions which can now accept an EVEX prefix need not be
further annotated in the op code map (x86-opcode-map.txt). In the case of
new instructions, the op code map is updated accordingly.

Also add associated Mask Instructions that are used to manipulate mask
registers used in AVX-512 instructions.

A representative set of instructions is added to the perf tools new
instructions test in a subsequent patch.
Signed-off-by: NAdrian Hunter <adrian.hunter@intel.com>
Acked-by: NIngo Molnar <mingo@kernel.org>
Acked-by: NMasami Hiramatsu <mhiramat@kernel.org>
Cc: Andy Lutomirski <luto@amacapital.net>
Cc: Dan Williams <dan.j.williams@intel.com>
Cc: H. Peter Anvin <hpa@zytor.com>
Cc: Jiri Olsa <jolsa@redhat.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: X86 ML <x86@kernel.org>
Link: http://lkml.kernel.org/r/1469003437-32706-4-git-send-email-adrian.hunter@intel.comSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>

Add support for Intel's AVX-512 instructions to the instruction decoder.

AVX-512 instructions are documented in Intel Architecture Instruction
Set Extensions Programming Reference (February 2016).

AVX-512 instructions are identified by a EVEX prefix which, for the
purpose of instruction decoding, can be treated as though it were a
4-byte VEX prefix.

Existing instructions which can now accept an EVEX prefix need not be
further annotated in the op code map (x86-opcode-map.txt). In the case
of new instructions, the op code map is updated accordingly.

Also add associated Mask Instructions that are used to manipulate mask
registers used in AVX-512 instructions.

The 'perf tools' instruction decoder is updated in a subsequent patch.
And a representative set of instructions is added to the perf tools new
instructions test in a subsequent patch.
Signed-off-by: NAdrian Hunter <adrian.hunter@intel.com>
Acked-by: NIngo Molnar <mingo@kernel.org>
Acked-by: NMasami Hiramatsu <mhiramat@kernel.org>
Cc: Andy Lutomirski <luto@amacapital.net>
Cc: Dan Williams <dan.j.williams@intel.com>
Cc: H. Peter Anvin <hpa@zytor.com>
Cc: Jiri Olsa <jolsa@redhat.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: X86 ML <x86@kernel.org>
Link: http://lkml.kernel.org/r/1469003437-32706-3-git-send-email-adrian.hunter@intel.comSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>

vcvtph2ps does not have an immediate operand, so remove the erroneous
'Ib' from its opcode map entry. Add vcvtph2ps to the perf tools new
instructions test to verify it.
Signed-off-by: NAdrian Hunter <adrian.hunter@intel.com>
Acked-by: NIngo Molnar <mingo@kernel.org>
Acked-by: NMasami Hiramatsu <mhiramat@kernel.org>
Cc: Andy Lutomirski <luto@amacapital.net>
Cc: Dan Williams <dan.j.williams@intel.com>
Cc: H. Peter Anvin <hpa@zytor.com>
Cc: Jiri Olsa <jolsa@redhat.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
Cc: X86 ML <x86@kernel.org>
Link: http://lkml.kernel.org/r/1469003437-32706-2-git-send-email-adrian.hunter@intel.comSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>

Merge tag 'perf-core-for-mingo-20160718' of git://git.kernel.org/pub/scm/linux/kernel/git/acme/linux into perf/core

Pull perf/core improvements and fixes from Arnaldo Carvalho de Melo:

User visible changes:

 - Properly report when a function wildcard produces no matches in 'perf probe'
   (Masami Hiramatsu)

 - Balance opening and reading events in 'perf stat', which could cause
   it to get stuck trying to close invalid file descriptors (Mark Rutland)

Infrastructure changes:

 - Copy more headers from the kernel, this time for headers that
   were just including the contents of its kernel counterparts, should
   help resolving the problems with linux-next, where some uapi related
   patches seem to be breaking tools/object/ build. (Arnaldo Carvalho de Melo)

   Some more combing will be done, but at least it is possible to build
   perf out of tree, via a detached tarball (make help | grep perf),
   without including kernel files in its MANIFEST (Arnaldo Carvalho de Melo)

 - Fix smatch found errors that were not causing problems, but are
   mistakes nonetheless (Dan Carpenter)

 - Fix string vs. byte array resolving in the python script code (Jiri Olsa)
Signed-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
Signed-off-by: NIngo Molnar <mingo@kernel.org>

Add automated test for is_printable_array function.
Signed-off-by: NJiri Olsa <jolsa@kernel.org>
Cc: David Ahern <dsahern@gmail.com>
Cc: Jiri Pirko <jiri@mellanox.com>
Cc: Namhyung Kim <namhyung@kernel.org>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: Steven Rostedt <rostedt@goodmis.org>
Link: http://lkml.kernel.org/r/1468685480-18951-4-git-send-email-jolsa@kernel.orgSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>

It's used from 2 objects in perf, so it's better to keep just one copy.
Signed-off-by: NJiri Olsa <jolsa@kernel.org>
Cc: David Ahern <dsahern@gmail.com>
Cc: Jiri Pirko <jiri@mellanox.com>
Cc: Namhyung Kim <namhyung@kernel.org>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: Steven Rostedt <rostedt@goodmis.org>
Link: http://lkml.kernel.org/r/1468685480-18951-3-git-send-email-jolsa@kernel.orgSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>

Jirka reported that python code returns all arrays as strings.  This
makes impossible to get all items for byte array tracepoint field
containing 0x00 value item.

Fixing this by scanning full length of the array and returning it as
PyByteArray object in case non printable byte is found.
Signed-off-by: NJiri Olsa <jolsa@kernel.org>
Reported-and-Tested-by: NJiri Pirko <jiri@mellanox.com>
Cc: David Ahern <dsahern@gmail.com>
Cc: Namhyung Kim <namhyung@kernel.org>
Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
Cc: Steven Rostedt <rostedt@goodmis.org>
Link: http://lkml.kernel.org/r/1468685480-18951-2-git-send-email-jolsa@kernel.orgSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>

Warn unmatched function filter correctly instead of warning
"symbol-loading error", since that can be a filter issue.

From the technical point of view, this adds a filter chech in map__load
and if there is a filter, it returns -2 (filter-out), instead of -1
(error), and perf-probe checks it and change message.

E.g. without this fix:

  # perf probe -F rt_sp*
  no symbols found in [kernel.kallsyms], maybe install a debug package?
  Failed to load symbols in kernel

With this fix:

  # perf probe -F rt_sp*
  no symbols passed the given filter.
  Failed to find symbols matched to "rt_sp*"
    Error: Failed to show functions.
Reported-and-Tested-by: NArnaldo Carvalho de Melo <acme@redhat.com>
Signed-off-by: NMasami Hiramatsu <mhiramat@kernel.org>
Cc: Namhyung Kim <namhyung@kernel.org>
Cc: Peter Zijlstra <peterz@infradead.org>
Link: http://lkml.kernel.org/r/146885835596.16106.2293540792775552481.stgit@devboxSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>

In some cases it's necessry to figure out the map-local index of a given
Linux logical CPU ID. Add a new helper, cpu_map__idx, to acquire this.
As the logic is largely the same as the existing cpu_map__has, this is
rewritten in terms of the new helper.

At the same time, add the inverse operation, cpu_map__cpu, which yields
the logical CPU id for a map-local index. While this can be performed
manually, wrapping this in a helper can make code more legible.
Signed-off-by: NMark Rutland <mark.rutland@arm.com>
Acked-by: NJiri Olsa <jolsa@kernel.org>
Cc: Adrian Hunter <adrian.hunter@intel.com>
Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
Cc: He Kuang <hekuang@huawei.com>
Cc: Kan Liang <kan.liang@intel.com>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Wang Nan <wangnan0@huawei.com>
Link: http://lkml.kernel.org/r/1468577293-19667-3-git-send-email-mark.rutland@arm.comSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>

In create_perf_stat_counter, when a target CPU has not been provided, we
call __perf_evsel__open with empty_cpu_map, and open a single FD per
thread. However, in read_counter we assume that we opened events for the
product of threads and CPUs described in the evsel's cpu_map.

Thus, if an evsel has a cpu_map with more than one entry, we will
attempt to access FDs that we didn't open. This could result in a number
of problems (e.g. blocking while reading from STDIN if the fd memory
happened to be initialised to zero).

This is problematic for systems were a logical CPU PMU covers some
arbitrary subset of CPUs. The cpu_map of any evsel for that PMU will be
initialised based on the cpumask exposed through sysfs, even if the user
requests per-thread events.
Signed-off-by: NMark Rutland <mark.rutland@arm.com>
Acked-by: NJiri Olsa <jolsa@kernel.org>
Cc: Adrian Hunter <adrian.hunter@intel.com>
Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
Cc: He Kuang <hekuang@huawei.com>
Cc: Kan Liang <kan.liang@intel.com>
Cc: Mark Rutland <mark.rutland@arm.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Wang Nan <wangnan0@huawei.com>
Link: http://lkml.kernel.org/r/1468577293-19667-2-git-send-email-mark.rutland@arm.comSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>

We were also using this directly from the kernel sources, the two last
cases, fix it.

Cc: Adrian Hunter <adrian.hunter@intel.com>
Cc: David Ahern <dsahern@gmail.com>
Cc: Jiri Olsa <jolsa@kernel.org>
Cc: Namhyung Kim <namhyung@kernel.org>
Cc: Wang Nan <wangnan0@huawei.com>
Link: http://lkml.kernel.org/n/tip-7o14xvacqcjc5llc7gvjjyl8@git.kernel.orgSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>

It hasn't been used since we made tools/ self sufficiente wrt list.h.

Cc: Adrian Hunter <adrian.hunter@intel.com>
Cc: David Ahern <dsahern@gmail.com>
Cc: Jiri Olsa <jolsa@kernel.org>
Cc: Josh Poimboeuf <jpoimboe@redhat.com>
Cc: Namhyung Kim <namhyung@kernel.org>
Cc: Wang Nan <wangnan0@huawei.com>
Fixes: d1b39d41 ("tools: Make list.h self-sufficient")
Link: http://lkml.kernel.org/n/tip-w20ueqlf22kh7ctjqo0zjpig@git.kernel.orgSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>

copy some more kernel files accessed from tools/, check for drift.

Cc: Adrian Hunter <adrian.hunter@intel.com>
Cc: David Ahern <dsahern@gmail.com>
Cc: Jiri Olsa <jolsa@kernel.org>
Cc: Namhyung Kim <namhyung@kernel.org>
Cc: Wang Nan <wangnan0@huawei.com>
Link: http://lkml.kernel.org/n/tip-omz8xdyvvxgjiuqzwj6ecm6j@git.kernel.orgSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>

No need to copy it to a detached tarball as they aren't used anymore

Cc: Adrian Hunter <adrian.hunter@intel.com>
Cc: David Ahern <dsahern@gmail.com>
Cc: Jiri Olsa <jolsa@kernel.org>
Cc: Namhyung Kim <namhyung@kernel.org>
Cc: Wang Nan <wangnan0@huawei.com>
Link: http://lkml.kernel.org/n/tip-lopmaqi439ke10g1j9cxrxwt@git.kernel.orgSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>

Not used anymore, remove one more file referencing kernel sources, i.e.
outside of tools/

Cc: Adrian Hunter <adrian.hunter@intel.com>
Cc: David Ahern <dsahern@gmail.com>
Cc: Jiri Olsa <jolsa@kernel.org>
Cc: Namhyung Kim <namhyung@kernel.org>
Cc: Wang Nan <wangnan0@huawei.com>
Link: http://lkml.kernel.org/n/tip-ykfjt3t8l0npxfwmekiwwyu6@git.kernel.orgSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>

Not used anymore. This also stops include linux/swab.h directly
from the kernel sources, remove that reference from the MANIFEST.

Cc: Adrian Hunter <adrian.hunter@intel.com>
Cc: David Ahern <dsahern@gmail.com>
Cc: Jiri Olsa <jolsa@kernel.org>
Cc: Namhyung Kim <namhyung@kernel.org>
Cc: Wang Nan <wangnan0@huawei.com>
Signed-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>

It uses the likely/unlikely macros, so need to include
<linux/compiler.h>.

Cc: Adrian Hunter <adrian.hunter@intel.com>
Cc: David Ahern <dsahern@gmail.com>
Cc: Jiri Olsa <jolsa@kernel.org>
Cc: Namhyung Kim <namhyung@kernel.org>
Cc: Wang Nan <wangnan0@huawei.com>
Link: http://lkml.kernel.org/n/tip-p0xrhgbkicsii9ohmhhprqpi@git.kernel.orgSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>

The 'info.e_machine' struct member is an uint16_t so 'm' is never less
than zero.  It looks like this was maybe left over code from earlier
versions so I've just removed it.
Signed-off-by: NDan Carpenter <dan.carpenter@oracle.com>
Cc: Adrian Hunter <adrian.hunter@intel.com>
Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
Cc: Peter Zijlstra <peterz@infradead.org>
Cc: Stephane Eranian <eranian@google.com>
Cc: kernel-janitors@vger.kernel.org
Link: http://lkml.kernel.org/r/20160715210836.GB19522@mwandaSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>