1. 03 4月, 2018 2 次提交
  2. 17 3月, 2018 1 次提交
  3. 19 2月, 2018 1 次提交
    • J
      perf tools: Add Python 3 support · 66dfdff0
      Jaroslav Škarvada 提交于
      Added Python 3 support while keeping Python 2.7 compatibility.
      
      Committer notes:
      
      This doesn't make it to auto detect python 3, one has to explicitely ask
      it to build with python 3 devel files, here are the instructions
      provided by Jaroslav:
      
       ---
        $ cp -a tools/perf tools/python3-perf
        $ make V=1 prefix=/usr -C tools/perf PYTHON=/usr/bin/python2 all
        $ make V=1 prefix=/usr -C tools/python3-perf PYTHON=/usr/bin/python3 all
        $ make V=1 prefix=/usr -C tools/python3-perf PYTHON=/usr/bin/python3 DESTDIR=%{buildroot} install-python_ext
        $ make V=1 prefix=/usr -C tools/perf PYTHON=/usr/bin/python2 DESTDIR=%{buildroot} install-python_ext
       ---
      
      We need to make this automatic, just like the existing tests for checking if
      the python2 devel files are in place, allowing the build with python3 if
      available, fallbacking to python2 and then just disabling it if none are
      available.
      
      So, using the PYTHON variable to build it using O= we get:
      
      Before this patch:
      
        $ rpm -q python3 python3-devel
        python3-3.6.4-7.fc27.x86_64
        python3-devel-3.6.4-7.fc27.x86_64
        $ rm -rf /tmp/build/perf/ ; mkdir -p /tmp/build/perf ; make O=/tmp/build/perf PYTHON=/usr/bin/python3 -C tools/perf install-bin
        make: Entering directory '/home/acme/git/linux/tools/perf'
        <SNIP>
        Makefile.config:670: Python 3 is not yet supported; please set
        Makefile.config:671: PYTHON and/or PYTHON_CONFIG appropriately.
        Makefile.config:672: If you also have Python 2 installed, then
        Makefile.config:673: try something like:
        Makefile.config:674:
        Makefile.config:675:   make PYTHON=python2
        Makefile.config:676:
        Makefile.config:677: Otherwise, disable Python support entirely:
        Makefile.config:678:
        Makefile.config:679:   make NO_LIBPYTHON=1
        Makefile.config:680:
        Makefile.config:681: *** .  Stop.
        make[1]: *** [Makefile.perf:212: sub-make] Error 2
        make: *** [Makefile:110: install-bin] Error 2
        make: Leaving directory '/home/acme/git/linux/tools/perf'
        $
      
      After:
      
        $ make O=/tmp/build/perf PYTHON=python3 -C tools/perf install-bin
        $ ldd ~/bin/perf | grep python
      	libpython3.6m.so.1.0 => /lib64/libpython3.6m.so.1.0 (0x00007f58a31e8000)
        $ rpm -qf /lib64/libpython3.6m.so.1.0
        python3-libs-3.6.4-7.fc27.x86_64
        $
      
      Now verify that when using the binding the right ELF file is loaded,
      using perf trace:
      
        $ perf trace -e open* perf test python
           0.051 ( 0.016 ms): perf/3927 openat(dfd: CWD, filename: /etc/ld.so.cache, flags: CLOEXEC           ) = 3
      <SNIP>
        18: 'import perf' in python                               :
           8.849 ( 0.013 ms): sh/3929 openat(dfd: CWD, filename: /etc/ld.so.cache, flags: CLOEXEC           ) = 3
      <SNIP>
          25.572 ( 0.008 ms): python3/3931 openat(dfd: CWD, filename: /tmp/build/perf/python/perf.cpython-36m-x86_64-linux-gnu.so, flags: CLOEXEC) = 3
      <SNIP>
       Ok
      <SNIP>
        $
      
      And using tools/perf/python/twatch.py, to show PERF_RECORD_ metaevents:
      
        $ python3 tools/perf/python/twatch.py
        cpu: 3, pid: 16060, tid: 16060 { type: fork, pid: 5207, ppid: 16060, tid: 5207, ptid: 16060, time: 10798513015459}
        cpu: 3, pid: 16060, tid: 16060 { type: fork, pid: 5208, ppid: 16060, tid: 5208, ptid: 16060, time: 10798513562503}
        cpu: 0, pid: 5208, tid: 5208 { type: comm, pid: 5208, tid: 5208, comm: grep }
        cpu: 2, pid: 5207, tid: 5207 { type: comm, pid: 5207, tid: 5207, comm: ps }
        cpu: 2, pid: 5207, tid: 5207 { type: exit, pid: 5207, ppid: 5207, tid: 5207, ptid: 5207, time: 10798551337484}
        cpu: 3, pid: 5208, tid: 5208 { type: exit, pid: 5208, ppid: 5208, tid: 5208, ptid: 5208, time: 10798551292153}
        cpu: 3, pid: 601, tid: 601 { type: fork, pid: 5209, ppid: 601, tid: 5209, ptid: 601, time: 10801779977324}
        ^CTraceback (most recent call last):
          File "tools/perf/python/twatch.py", line 68, in <module>
            main()
          File "tools/perf/python/twatch.py", line 40, in main
            evlist.poll(timeout = -1)
        KeyboardInterrupt
        $
      
        # ps ax|grep twatch
       5197 pts/8    S+     0:00 python3 tools/perf/python/twatch.py
        # ls -la /proc/5197/smaps
        -r--r--r--. 1 acme acme 0 Feb 19 13:14 /proc/5197/smaps
        # grep python /proc/5197/smaps
        558111307000-558111309000 r-xp 00000000 fd:00 3151710  /usr/bin/python3.6
        558111508000-558111509000 r--p 00001000 fd:00 3151710  /usr/bin/python3.6
        558111509000-55811150a000 rw-p 00002000 fd:00 3151710  /usr/bin/python3.6
        7ffad6fc1000-7ffad7008000 r-xp 00000000 00:2d 220196   /tmp/build/perf/python/perf.cpython-36m-x86_64-linux-gnu.so
        7ffad7008000-7ffad7207000 ---p 00047000 00:2d 220196   /tmp/build/perf/python/perf.cpython-36m-x86_64-linux-gnu.so
        7ffad7207000-7ffad7208000 r--p 00046000 00:2d 220196   /tmp/build/perf/python/perf.cpython-36m-x86_64-linux-gnu.so
        7ffad7208000-7ffad7215000 rw-p 00047000 00:2d 220196   /tmp/build/perf/python/perf.cpython-36m-x86_64-linux-gnu.so
        7ffadea77000-7ffaded3d000 r-xp 00000000 fd:00 3151795  /usr/lib64/libpython3.6m.so.1.0
        7ffaded3d000-7ffadef3c000 ---p 002c6000 fd:00 3151795  /usr/lib64/libpython3.6m.so.1.0
        7ffadef3c000-7ffadef42000 r--p 002c5000 fd:00 3151795  /usr/lib64/libpython3.6m.so.1.0
        7ffadef42000-7ffadefa5000 rw-p 002cb000 fd:00 3151795  /usr/lib64/libpython3.6m.so.1.0
        #
      
      And with this patch, but building normally, without specifying the
      PYTHON=python3 part, which will make it use python2 if its devel files are
      available, like in this test:
      
        $ make O=/tmp/build/perf -C tools/perf install-bin
        $ ldd ~/bin/perf | grep python
      	libpython2.7.so.1.0 => /lib64/libpython2.7.so.1.0 (0x00007f6a44410000)
        $ ldd /tmp/build/perf/python_ext_build/lib/perf.so  | grep python
      	libpython2.7.so.1.0 => /lib64/libpython2.7.so.1.0 (0x00007fed28a2c000)
        $
      
        [acme@jouet perf]$ tools/perf/python/twatch.py
        cpu: 0, pid: 2817, tid: 2817 { type: fork, pid: 2817, ppid: 2817, tid: 8910, ptid: 2817, time: 11126454335306}
        cpu: 0, pid: 2817, tid: 2817 { type: comm, pid: 2817, tid: 8910, comm: worker }
        $ ps ax | grep twatch.py
         8909 pts/8    S+     0:00 /usr/bin/python tools/perf/python/twatch.py
        $ grep python /proc/8909/smaps
        5579de658000-5579de659000 r-xp 00000000 fd:00 3156044  /usr/bin/python2.7
        5579de858000-5579de859000 r--p 00000000 fd:00 3156044  /usr/bin/python2.7
        5579de859000-5579de85a000 rw-p 00001000 fd:00 3156044  /usr/bin/python2.7
        7f0de01f7000-7f0de023e000 r-xp 00000000 00:2d 230695   /tmp/build/perf/python/perf.so
        7f0de023e000-7f0de043d000 ---p 00047000 00:2d 230695   /tmp/build/perf/python/perf.so
        7f0de043d000-7f0de043e000 r--p 00046000 00:2d 230695   /tmp/build/perf/python/perf.so
        7f0de043e000-7f0de044b000 rw-p 00047000 00:2d 230695   /tmp/build/perf/python/perf.so
        7f0de6f0f000-7f0de6f13000 r-xp 00000000 fd:00 134975   /usr/lib64/python2.7/lib-dynload/_localemodule.so
        7f0de6f13000-7f0de7113000 ---p 00004000 fd:00 134975   /usr/lib64/python2.7/lib-dynload/_localemodule.so
        7f0de7113000-7f0de7114000 r--p 00004000 fd:00 134975   /usr/lib64/python2.7/lib-dynload/_localemodule.so
        7f0de7114000-7f0de7115000 rw-p 00005000 fd:00 134975   /usr/lib64/python2.7/lib-dynload/_localemodule.so
        7f0de7e73000-7f0de8052000 r-xp 00000000 fd:00 3173292  /usr/lib64/libpython2.7.so.1.0
        7f0de8052000-7f0de8251000 ---p 001df000 fd:00 3173292  /usr/lib64/libpython2.7.so.1.0
        7f0de8251000-7f0de8255000 r--p 001de000 fd:00 3173292  /usr/lib64/libpython2.7.so.1.0
        7f0de8255000-7f0de8291000 rw-p 001e2000 fd:00 3173292  /usr/lib64/libpython2.7.so.1.0
        $
      Signed-off-by: NJaroslav Škarvada <jskarvad@redhat.com>
      Tested-by: NArnaldo Carvalho de Melo <acme@redhat.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>
      LPU-Reference: 20180119205641.24242-1-jskarvad@redhat.com
      Link: https://lkml.kernel.org/n/tip-8d7dt9kqp83vsz25hagug8fu@git.kernel.org
      [ Removed explicit check for python version, allowing it to really build with python3 ]
      Signed-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      66dfdff0
  4. 17 2月, 2018 1 次提交
  5. 25 1月, 2018 1 次提交
  6. 23 1月, 2018 2 次提交
  7. 08 1月, 2018 1 次提交
  8. 27 12月, 2017 3 次提交
  9. 18 12月, 2017 2 次提交
    • 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
  10. 06 12月, 2017 1 次提交
    • J
      perf tools: Fix up build in hardnened environments · c6707fde
      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>
      c6707fde
  11. 05 12月, 2017 2 次提交
  12. 17 11月, 2017 1 次提交
  13. 16 11月, 2017 1 次提交
  14. 29 8月, 2017 1 次提交
  15. 23 8月, 2017 2 次提交
  16. 19 7月, 2017 1 次提交
  17. 21 6月, 2017 1 次提交
  18. 15 6月, 2017 1 次提交
    • J
      perf tools: Fix build with ARCH=x86_64 · 7a759cd8
      Jiada Wang 提交于
      With commit: 0a943cb1 (tools build: Add HOSTARCH Makefile variable)
      when building for ARCH=x86_64, ARCH=x86_64 is passed to perf instead of
      ARCH=x86, so the perf build process searchs header files from
      tools/arch/x86_64/include, which doesn't exist.
      
      The following build failure is seen:
      
        In file included from util/event.c:2:0:
          tools/include/uapi/linux/mman.h:4:27: fatal error: uapi/asm/mman.h: No such file or directory
          compilation terminated.
      
      Fix this issue by using SRCARCH instead of ARCH in perf, just like the
      main kernel Makefile and tools/objtool's.
      Signed-off-by: NJiada Wang <jiada_wang@mentor.com>
      Tested-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      Acked-by: NJiri Olsa <jolsa@kernel.org>
      Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
      Cc: Andi Kleen <ak@linux.intel.com>
      Cc: Eugeniu Rosca <erosca@de.adit-jv.com>
      Cc: Jan Stancek <jstancek@redhat.com>
      Cc: Masami Hiramatsu <mhiramat@kernel.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Ravi Bangoria <ravi.bangoria@linux.vnet.ibm.com>
      Cc: Rui Teng <rui.teng@linux.vnet.ibm.com>
      Cc: Sukadev Bhattiprolu <sukadev@linux.vnet.ibm.com>
      Cc: Wang Nan <wangnan0@huawei.com>
      Fixes: 0a943cb1 ("tools build: Add HOSTARCH Makefile variable")
      Link: http://lkml.kernel.org/r/1491793357-14977-2-git-send-email-jiada_wang@mentor.comSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      7a759cd8
  19. 13 4月, 2017 1 次提交
  20. 12 4月, 2017 1 次提交
  21. 04 3月, 2017 1 次提交
  22. 17 2月, 2017 1 次提交
    • A
      tools perf scripting python: clang doesn't have -spec, remove it · 8bd8c653
      Arnaldo Carvalho de Melo 提交于
      Gcc has a -spec option to override what options to pass to cc, etc, and
      in some distros this is used, like in fedora, where we end up getting
      this passed to gcc that makes clang, that doesn't have this option to
      stop the build:
      
        CC       /tmp/build/perf/util/scripting-engines/trace-event-python.o
      clang-4.0: error: argument unused during compilation: '-specs=/usr/lib/rpm/redhat/redhat-hardened-cc1' [-Werror,-Wunused-command-line-argument]
      
      So filter this out when the compiler used is clang, this way we
      can build the python scripting support in tools/perf/.
      
      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-2gosxoiouf24pnlknp7w7q4z@git.kernel.orgSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      8bd8c653
  23. 14 2月, 2017 1 次提交
  24. 17 1月, 2017 1 次提交
  25. 07 12月, 2016 1 次提交
    • W
      perf build: Check LLVM version in feature check · a940cad3
      Wang Nan 提交于
      Cancel builtin llvm and clang support when LLVM version is less than
      3.9.0: following commits uses newer API.
      
      Since Clang/LLVM's API is not guaranteed to be stable, add a
      test-llvm-version.cpp feature checker, issue warning if LLVM found in
      compiling environment is not tested yet.
      
      Committer Notes:
      
      Testing it:
      
      Environment:
      
        $ cat /etc/fedora-release
        Fedora release 25 (Twenty Five)
        $ rpm -q llvm-devel clang-devel
        llvm-devel-3.8.0-1.fc25.x86_64
        clang-devel-3.8.0-2.fc25.x86_64
        $
      
      Before:
      
        $  make -k LIBCLANGLLVM=1 O=/tmp/build/perf -C tools/perf install-bin
        make: Entering directory '/home/acme/git/linux/tools/perf'
          BUILD:   Doing 'make -j4' parallel build
        Warning: tools/include/uapi/linux/bpf.h differs from kernel
        Warning: tools/arch/arm/include/uapi/asm/kvm.h differs from kernel
          INSTALL  GTK UI
          LINK     /tmp/build/perf/perf
        /tmp/build/perf/libperf.a(libperf-in.o): In function `perf::createCompilerInvocation(llvm::SmallVector<char const*, 16u>, llvm::StringRef&, clang::DiagnosticsEngine&)':
        /home/acme/git/linux/tools/perf/util/c++/clang.cpp:56: undefined reference to `clang::tooling::newInvocation(clang::DiagnosticsEngine*, llvm::SmallVector<char const*, 16u> const&)'
        /tmp/build/perf/libperf.a(libperf-in.o): In function `perf::getModuleFromSource(llvm::SmallVector<char const*, 16u>, llvm::StringRef, llvm::IntrusiveRefCntPtr<clang::vfs::FileSystem>)':
        /home/acme/git/linux/tools/perf/util/c++/clang.cpp:68: undefined reference to `clang::CompilerInstance::CompilerInstance(std::shared_ptr<clang::PCHContainerOperations>, bool)'
        /home/acme/git/linux/tools/perf/util/c++/clang.cpp:69: undefined reference to `clang::CompilerInstance::createDiagnostics(clang::DiagnosticConsumer*, bool)'
        <SNIP>
      
      After:
      
        Makefile.config:807: No suitable libLLVM found, disabling builtin clang and llvm support. Please install llvm-dev(el) (>= 3.9.0)
      
      Updating the environment to a locally built LLVM 4.0 + clang 3.9 (forgot
      to git pull, duh) combo, all works as expected, it is properly detected
      and built into the resulting perf binary.
      Signed-off-by: NWang Nan <wangnan0@huawei.com>
      Reported-and-Tested-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      Cc: Alexei Starovoitov <ast@fb.com>
      Cc: He Kuang <hekuang@huawei.com>
      Cc: Jiri Olsa <jolsa@kernel.org>
      Cc: Joe Stringer <joe@ovn.org>
      Cc: Zefan Li <lizefan@huawei.com>
      Cc: pi3orama@163.com
      Link: http://lkml.kernel.org/r/20161206072230.7651-1-wangnan0@huawei.com
      [ Change the warning message a bit (add 'suitable' and 'builtin'), clarifying it, see committer notes above ]
      Signed-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      a940cad3
  26. 06 12月, 2016 2 次提交
  27. 14 11月, 2016 1 次提交
  28. 24 10月, 2016 1 次提交
  29. 22 9月, 2016 1 次提交
  30. 03 8月, 2016 1 次提交
  31. 14 7月, 2016 1 次提交
  32. 13 7月, 2016 1 次提交
    • A
      perf tools: Add feature detection for gelf_getnote() · 1c1a3a47
      Arnaldo Carvalho de Melo 提交于
      That is not present on some libelf implementations, such as the one used
      in Alpine Linux: libelf-0.8.13.
      
      This ends up disabling the SDT code, that relies on this function.
      
      One alternative would be to provide an weak fallback implementation or
      the open coded variant used by the buildid sysfs notes reading code.
      
      Cc: Adrian Hunter <adrian.hunter@intel.com>
      Cc: Ananth N Mavinakayanahalli <ananth@linux.vnet.ibm.com>
      Cc: Brendan Gregg <brendan.d.gregg@gmail.com>
      Cc: David Ahern <dsahern@gmail.com>
      Cc: Hemant Kumar <hemant@linux.vnet.ibm.com>
      Cc: Jiri Olsa <jolsa@kernel.org>
      Cc: Masami Hiramatsu <mhiramat@kernel.org>
      Cc: Namhyung Kim <namhyung@kernel.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Wang Nan <wangnan0@huawei.com>
      Link: http://lkml.kernel.org/n/tip-82lh22ybedy9b9lych8xj12g@git.kernel.orgSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      1c1a3a47