1. 27 12月, 2017 4 次提交
  2. 18 12月, 2017 4 次提交
    • A
      tools arch s390: Do not include header files from the kernel sources · 10b9baa7
      Arnaldo Carvalho de Melo 提交于
      Long ago we decided to be verbotten including files in the kernel git
      sources from tools/ living source code, to avoid disturbing kernel
      development (and perf's and other tools/) when, say, a kernel hacker
      adds something, tests everything but tools/ and have tools/ build
      broken.
      
      This got broken recently by s/390, fix it by copying
      arch/s390/include/uapi/asm/perf_regs.h to tools/arch/s390/include/uapi/asm/,
      making this one be used by means of <asm/perf_regs.h> and updating
      tools/perf/check_headers.sh to make sure we are notified when the
      original changes, so that we can check if anything is needed on the
      tooling side.
      
      This would have been caught by the 'tarkpg' test entry in:
      
      $ make -C tools/perf build-test
      
      When run on a s/390 build system or container.
      Acked-by: NHeiko Carstens <heiko.carstens@de.ibm.com>
      Cc: Hendrik Brueckner <brueckner@linux.vnet.ibm.com>
      Cc: Thomas Richter <tmricht@linux.vnet.ibm.com>
      Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
      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: f704ef44 ("s390/perf: add support for perf_regs and libdw")
      Link: https://lkml.kernel.org/n/tip-n57139ic0v9uffx8wdqi3d8a@git.kernel.orgSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      10b9baa7
    • B
      perf jvmti: Generate correct debug information for inlined code · ca58d7e6
      Ben Gainey 提交于
      tools/perf/jvmti is broken in so far as it generates incorrect debug
      information. Specifically it attributes all debug lines to the original
      method being output even in the case that some code is being inlined
      from elsewhere.  This patch fixes the issue.
      
      To test (from within linux/tools/perf):
      
      export JDIR=/usr/lib/jvm/java-8-openjdk-amd64/
      make
      cat << __EOF > Test.java
      public class Test
      {
          private StringBuilder b = new StringBuilder();
      
          private void loop(int i, String... args)
          {
              for (String a : args)
                  b.append(a);
      
              long hc = b.hashCode() * System.nanoTime();
      
              b = new StringBuilder();
              b.append(hc);
      
              System.out.printf("Iteration %d = %d\n", i, hc);
          }
      
          public void run(String... args)
          {
              for (int i = 0; i < 10000; ++i)
              {
                  loop(i, args);
              }
          }
      
          public static void main(String... args)
          {
              Test t = new Test();
              t.run(args);
          }
      }
      __EOF
      $JDIR/bin/javac Test.java
      ./perf record -F 10000 -g -k mono $JDIR/bin/java -agentpath:`pwd`/libperf-jvmti.so Test
      ./perf inject --jit -i perf.data -o perf.data.jitted
      ./perf annotate -i perf.data.jitted --stdio | grep Test\.java: | sort -u
      
      Before this patch, Test.java line numbers get reported that are greater
      than the number of lines in the Test.java file.  They come from the
      source file of the inlined function, e.g. java/lang/String.java:1085.
      For further validation one can examine those lines in the JDK source
      distribution and confirm that they map to inlined functions called by
      Test.java.
      
      After this patch, the filename of the inlined function is output
      rather than the incorrect original source filename.
      Signed-off-by: NBen Gainey <ben.gainey@arm.com>
      Tested-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      Tested-by: NStephane Eranian <eranian@google.com>
      Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
      Cc: Ben Gainey <ben.gainey@arm.com>
      Cc: Colin King <colin.king@canonical.com>
      Cc: Darren Hart <dvhart@infradead.org>
      Cc: Jiri Olsa <jolsa@redhat.com>
      Cc: Namhyung Kim <namhyung@kernel.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Fixes: 598b7c69 ("perf jit: add source line info support")
      Link: http://lkml.kernel.org/r/20171122182541.d25599a3eb1ada3480d142fa@arm.comSigned-off-by: NKim Phillips <kim.phillips@arm.com>
      Signed-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      ca58d7e6
    • J
      perf tools: Fix up build in hardened environments · 61fb26a6
      Jiri Olsa 提交于
      On Fedora systems the perl and python CFLAGS/LDFLAGS include the
      hardened specs from redhat-rpm-config package. We apply them only for
      perl/python objects, which makes them not compatible with the rest of
      the objects and the build fails with:
      
        /usr/bin/ld: perf-in.o: relocation R_X86_64_32 against `.rodata.str1.1' can not be used when making a shared object; recompile with -f
      +PIC
        /usr/bin/ld: libperf.a(libperf-in.o): relocation R_X86_64_32S against `.text' can not be used when making a shared object; recompile w
      +ith -fPIC
        /usr/bin/ld: final link failed: Nonrepresentable section on output
        collect2: error: ld returned 1 exit status
        make[2]: *** [Makefile.perf:507: perf] Error 1
        make[1]: *** [Makefile.perf:210: sub-make] Error 2
        make: *** [Makefile:69: all] Error 2
      
      Mainly it's caused by perl/python objects being compiled with:
      
        -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1
      
      which prevent the final link impossible, because it will check
      for 'proper' objects with following option:
      
        -specs=/usr/lib/rpm/redhat/redhat-hardened-ld
      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 <peterz@infradead.org>
      Link: https://lkml.kernel.org/r/20171204082437.GC30564@kravaSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      61fb26a6
    • J
      perf tools: Use shell function for perl cflags retrieval · 5cfee7a3
      Jiri Olsa 提交于
      Using the shell function for perl CFLAGS retrieval instead of back
      quotes (``). Both execute shell with the command, but the latter is more
      explicit and seems to be the preferred way.
      
      Also we don't have any other use of the back quotes in perf Makefiles.
      Signed-off-by: NJiri Olsa <jolsa@kernel.org>
      Cc: David Ahern <dsahern@gmail.com>
      Cc: Namhyung Kim <namhyung@kernel.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Link: http://lkml.kernel.org/r/20171108102739.30338-2-jolsa@kernel.orgSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      5cfee7a3
  3. 15 12月, 2017 1 次提交
  4. 12 12月, 2017 1 次提交
  5. 07 12月, 2017 1 次提交
    • I
      tooling/headers: Synchronize updated s390 and x86 UAPI headers · 34c9ca37
      Ingo Molnar 提交于
      There were two trivial updates to these upstream UAPI headers:
      
        arch/s390/include/uapi/asm/kvm.h
        arch/s390/include/uapi/asm/kvm_perf.h
        arch/x86/lib/x86-opcode-map.txt
      
      Synchronize them with their tooling copies.
      
      (The x86 opcode map includes a new instruction pattern now.)
      
      Cc: Arnaldo Carvalho de Melo <acme@redhat.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Namhyung Kim <namhyung@kernel.org>
      Cc: Jiri Olsa <jolsa@redhat.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Cc: linux-kernel@vger.kernel.org
      Signed-off-by: NIngo Molnar <mingo@kernel.org>
      34c9ca37
  6. 06 12月, 2017 15 次提交
  7. 05 12月, 2017 11 次提交
  8. 01 12月, 2017 1 次提交
  9. 30 11月, 2017 2 次提交
    • A
      perf intel-pt: Improve build messages for files that differ from the kernel · c2653297
      Adrian Hunter 提交于
      Print file names of files that differ. For example, instead of:
      
        Warning: Intel PT: x86 instruction decoder differs from kernel
      
      print:
      
        Warning: Intel PT: x86 instruction decoder header at 'tools/perf/util/intel-pt-decoder/inat.h' differs from latest version at 'arch/x86/include/asm/inat.h'
      Reported-by: NIngo Molnar <mingo@kernel.org>
      Tested-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      Signed-off-by: NAdrian Hunter <adrian.hunter@intel.com>
      Link: http://lkml.kernel.org/r/1511253326-22308-2-git-send-email-adrian.hunter@intel.comSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      c2653297
    • A
      perf report: Fix -D output for user metadata events · f250b09c
      Arnaldo Carvalho de Melo 提交于
      The PERF_RECORD_USER_ events are synthesized by the tool to assist in
      processing the PERF_RECORD_ ones generated by the kernel, the printing
      of that information doesn't come with a perf_sample structure, so, when
      dumping the event fields using 'perf report -D' there were columns that
      end up not being printed.
      
      To tidy up a bit this, fake a perf_sample structure with zeroes to have
      the missing columns printed and avoid the occasional surprise with that.
      
      Before:
      
      0 0x45b8 [0x68]: PERF_RECORD_MMAP -1/0: [0xffffffffc12ec000(0x4000) @ 0]: x /lib/modules/4.14.0+/kernel/fs/nls/nls_utf8.ko
      0x4620 [0x28]: PERF_RECORD_THREAD_MAP nr: 1 thread: 27820
      0x4648 [0x18]: PERF_RECORD_CPU_MAP: 0-3
      0 0x4660 [0x28]: PERF_RECORD_COMM: perf:27820/27820
      0x4a58 [0x8]: PERF_RECORD_FINISHED_ROUND
      447723433020976 0x4688 [0x28]: PERF_RECORD_SAMPLE(IP, 0x4001): 27820/27820: 0xffffffff8f1b6d7a period: 1 addr: 0
      
      After:
      
        $ perf report -D | grep PERF_RECORD_ | head
        0 0xe8 [0x20]: PERF_RECORD_TIME_CONV: unhandled!
        0 0x108 [0x28]: PERF_RECORD_THREAD_MAP nr: 1 thread: 32555
        0 0x130 [0x18]: PERF_RECORD_CPU_MAP: 0-3
        0 0x148 [0x28]: PERF_RECORD_COMM: perf:32555/32555
        0 0x4e8 [0x8]: PERF_RECORD_FINISHED_ROUND
        448743409421205 0x170 [0x28]: PERF_RECORD_COMM exec: sleep:32555/32555
        448743409431883 0x198 [0x68]: PERF_RECORD_MMAP2 32555/32555: [0x55e11d75a000(0x208000) @ 0 fd:00 3147174 2566255743]: r-xp /usr/bin/sleep
        448743409443873 0x200 [0x70]: PERF_RECORD_MMAP2 32555/32555: [0x7f0ced316000(0x229000) @ 0 fd:00 3151761 2566238119]: r-xp /usr/lib64/ld-2.25.so
        448743409454790 0x270 [0x60]: PERF_RECORD_MMAP2 32555/32555: [0x7ffe84f6d000(0x2000) @ 0 00:00 0 0]: r-xp [vdso]
        448743409479500 0x2d0 [0x28]: PERF_RECORD_SAMPLE(IP, 0x4002): 32555/32555: 0xffffffff8f84c7e7 period: 1 addr: 0
        $
      
      Cc: Adrian Hunter <adrian.hunter@intel.com>
      Cc: Andi Kleen <ak@linux.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>
      Cc: Thomas Gleixner <tglx@linutronix.de>
      Fixes: 9aefcab0 ("perf session: Consolidate the dump code")
      Link: https://lkml.kernel.org/n/tip-todcu15x0cwgppkh1gi6uhru@git.kernel.orgSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      f250b09c