1. 28 5月, 2020 1 次提交
  2. 03 4月, 2020 2 次提交
  3. 06 1月, 2020 1 次提交
  4. 26 11月, 2019 1 次提交
    • J
      perf tools: Allow to link with libbpf dynamicaly · 7b65e203
      Jiri Olsa 提交于
      Currently we support only static linking with kernel's libbpf
      (tools/lib/bpf). This patch adds libbpf package detection and support to
      link perf with it dynamically.
      
      The libbpf package status is displayed with:
      
        $ make VF=1
        Auto-detecting system features:
        ...
        ...                        libbpf: [ on  ]
      
      It's not checked by default, because it's quite new.  Once it's on most
      distros we can switch it on.
      
      For the same reason it's not added to the test-all check.
      
      Perf does not need advanced version of libbpf, so we can check just for
      the base bpf_object__open function.
      
      Adding new compile variable to detect libbpf package and link bpf
      dynamically:
      
        $ make LIBBPF_DYNAMIC=1
          ...
          LINK     perf
        $ ldd perf | grep bpf
          libbpf.so.0 => /lib64/libbpf.so.0 (0x00007f46818bc000)
      
      If libbpf is not installed, build stops with:
      
        Makefile.config:486: *** Error: No libbpf devel library found,\
        please install libbpf-devel.  Stop.
      
      Committer testing:
      
        $ make LIBBPF_DYNAMIC=1 -C tools/perf O=/tmp/build/perf
        make: Entering directory '/home/acme/git/perf/tools/perf'
          BUILD:   Doing 'make -j8' parallel build
        Makefile.config:493: *** Error: No libbpf devel library found, please install libbpf-devel.  Stop.
        make[1]: *** [Makefile.perf:225: sub-make] Error 2
        make: *** [Makefile:70: all] Error 2
        make: Leaving directory '/home/acme/git/perf/tools/perf'
        $
      Signed-off-by: NJiri Olsa <jolsa@kernel.org>
      Tested-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      Cc: Toke Høiland-Jørgensen <toke@redhat.com>
      Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
      Cc: Alexei Starovoitov <alexei.starovoitov@gmail.com>
      Cc: Andrii Nakryiko <andriin@fb.com>
      Cc: Daniel Borkmann <daniel@iogearbox.net>
      Cc: Jesper Dangaard Brouer <brouer@redhat.com>
      Cc: Martin KaFai Lau <kafai@fb.com>
      Cc: Michael Petlan <mpetlan@redhat.com>
      Cc: Namhyung Kim <namhyung@kernel.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Song Liu <songliubraving@fb.com>
      Cc: Yonghong Song <yhs@fb.com>
      Cc: bpf@vger.kernel.org
      Cc: netdev@vger.kernel.org
      Link: http://lore.kernel.org/lkml/20191126121253.28253-1-jolsa@kernel.orgSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      7b65e203
  5. 15 10月, 2019 1 次提交
    • J
      perf tools: Allow to build with -ltcmalloc · bb91a073
      Jiri Olsa 提交于
      By using "make TCMALLOC=1" you can enable perf to be build for usage
      with libtcmalloc.so (gperftools).
      
      Get heap profile (tools/perf directory):
      
        $ <install gperftools>
        $ make TCMALLOC=1 DEBUG=1
        $ HEAPPROFILE=/tmp/heapprof ./perf ...
        $ pprof ./perf /tmp/heapprof.000*
        (pprof) top
        Total: 2335.5 MB
          1735.1  74.3%  74.3%   1735.1  74.3% memdup
           402.0  17.2%  91.5%    402.0  17.2% zalloc
           140.2   6.0%  97.5%    145.8   6.2% map__new
            33.6   1.4%  98.9%     33.6   1.4% symbol__new
            12.4   0.5%  99.5%     12.4   0.5% alloc_event
             6.2   0.3%  99.7%      6.2   0.3% nsinfo__new
             5.5   0.2% 100.0%      5.5   0.2% nsinfo__copy
             0.3   0.0% 100.0%      0.3   0.0% dso__new
             0.1   0.0% 100.0%      0.1   0.0% do_read_string
             0.0   0.0% 100.0%      0.0   0.0% __GI__IO_file_doallocate
      
      See callstack:
        $ pprof --pdf ./perf /tmp/heapprof.00* > callstack.pdf
        $ pprof --web ./perf /tmp/heapprof.00*
      
      Committer testing:
      
      Install gperftools, on fedora:
      
        # dnf install gperftools-devel
      
      Then build:
      
       $ make TCMALLOC=1 DEBUG=1 -C tools/perf O=/tmp/build/perf install-bin
      
      Verify that it linked against the right library:
      
        $ ldd ~/bin/perf | grep tcma
      	libtcmalloc.so.4 => /lib64/libtcmalloc.so.4 (0x00007fb2953a7000)
        $
      
      Run 'perf trace' system wide for 1 minute:
      
        # HEAPPROFILE=/tmp/heapprof perf trace -a sleep 1m
        <SNIP>
         59985.524 ( 0.006 ms): Web Content/20354 recvmsg(fd: 9<socket:[1762817]>, msg: 0x7ffee5fdafb0) = -1 EAGAIN (Resource temporarily unavailable)
         59985.536 ( 0.005 ms): Web Content/20354 recvmsg(fd: 9<socket:[1762817]>, msg: 0x7ffee5fdafc0) = -1 EAGAIN (Resource temporarily unavailable)
         59981.956 (10.143 ms): SCTP timer/21716  ... [continued]: select())                            = 0 (Timeout)
         59985.549 (         ): Web Content/20354 poll(ufds: 0x7f1df38af180, nfds: 3, timeout_msecs: 4294967295) ...
             0.926 (59999.481 ms): sleep/29764  ... [continued]: nanosleep())                           = 0
         59992.133 (         ): SCTP timer/21716 select(tvp: 0x7ff5bf7fee80)                            ...
         60000.477 ( 0.009 ms): sleep/29764 close(fd: 1)                                                = 0
         60000.493 ( 0.005 ms): sleep/29764 close(fd: 2)                                                = 0
         60000.514 (         ): sleep/29764 exit_group()                                                = ?
        Dumping heap profile to /tmp/heapprof.0001.heap (Exiting, 3 MB in use)
      [root@quaco ~]#
      
      Install pprof:
      
        # dnf install pprof
      
      And run it:
      
        # pprof ~/bin/perf /tmp/heapprof.0001.heap
        Using local file /root/bin/perf.
        Using local file /tmp/heapprof.0001.heap.
        Welcome to pprof!  For help, type 'help'.
        (pprof) top
        Total: 4.0 MB
             1.7  42.0%  42.0%      2.2  54.1% map__new
             0.9  23.3%  65.3%      0.9  23.3% zalloc
             0.5  11.4%  76.7%      0.5  11.4% dso__new
             0.2   5.6%  82.3%      0.3   8.5% trace__sys_enter
             0.2   4.9%  87.2%      0.2   4.9% __GI___strdup
             0.2   3.8%  91.0%      0.2   3.8% new_term
             0.1   2.2%  93.2%      0.4  10.1% __perf_pmu__new_alias
             0.0   1.0%  94.3%      0.0   1.2% event_read_fields
             0.0   0.8%  95.1%      0.0   0.8% nsinfo__new
             0.0   0.7%  95.8%      0.1   3.2% trace__read_syscall_info
        (pprof)
      Signed-off-by: NJiri Olsa <jolsa@kernel.org>
      Tested-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
      Cc: Andi Kleen <ak@linux.intel.com>
      Cc: Michael Petlan <mpetlan@redhat.com>
      Cc: Namhyung Kim <namhyung@kernel.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Link: http://lore.kernel.org/lkml/20191013151427.11941-2-jolsa@kernel.orgSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      bb91a073
  6. 11 10月, 2019 1 次提交
  7. 26 9月, 2019 1 次提交
  8. 05 9月, 2019 1 次提交
  9. 20 8月, 2019 1 次提交
  10. 13 8月, 2019 1 次提交
    • I
      tools build: Add capability-related feature detection · 74d5f3d0
      Igor Lubashev 提交于
      Add utilities to help checking capabilities of the running procss.  Make
      perf link with libcap, if it is available. If no libcap-dev[el], assume
      no capabilities.
      
      Committer testing:
      
        $ make O=/tmp/build/perf -C tools/perf install-bin
        make: Entering directory '/home/acme/git/perf/tools/perf'
          BUILD:   Doing 'make -j8' parallel build
      
        Auto-detecting system features:
        <SNIP>
        ...                        libbfd: [ on  ]
        ...                        libcap: [ OFF ]
        ...                        libelf: [ on  ]
        <SNIP>
        Makefile.config:833: No libcap found, disables capability support, please install libcap-devel/libcap-dev
        <SNIP>
        $ grep libcap /tmp/build/perf/FEATURE-DUMP
        feature-libcap=0
        $ cat /tmp/build/perf/feature/test-libcap.make.output
        test-libcap.c:2:10: fatal error: sys/capability.h: No such file or directory
            2 | #include <sys/capability.h>
              |          ^~~~~~~~~~~~~~~~~~
        compilation terminated.
        $
      
      Now install libcap-devel and try again:
      
        $ make O=/tmp/build/perf -C tools/perf install-bin
        make: Entering directory '/home/acme/git/perf/tools/perf'
          BUILD:   Doing 'make -j8' parallel build
        Warning: Kernel ABI header at 'tools/include/linux/bits.h' differs from latest version at 'include/linux/bits.h'
        diff -u tools/include/linux/bits.h include/linux/bits.h
        Warning: Kernel ABI header at 'tools/arch/x86/include/asm/cpufeatures.h' differs from latest version at 'arch/x86/include/asm/cpufeatures.h'
        diff -u tools/arch/x86/include/asm/cpufeatures.h arch/x86/include/asm/cpufeatures.h
      
        Auto-detecting system features:
        <SNIP>
        ...                        libbfd: [ on  ]
        ...                        libcap: [ on  ]
        ...                        libelf: [ on  ]
        <SNIP>>
          CC       /tmp/build/perf/jvmti/libjvmti.o
        <SNIP>>
        $ grep libcap /tmp/build/perf/FEATURE-DUMP
        feature-libcap=1
        $ cat /tmp/build/perf/feature/test-libcap.make.output
        $ ldd /tmp/build/perf/feature/test-libcap.make.bin
        ldd: /tmp/build/perf/feature/test-libcap.make.bin: No such file or directory
        $ ldd /tmp/build/perf/feature/test-libcap.bin
        	linux-vdso.so.1 (0x00007ffc35bfe000)
        	libcap.so.2 => /lib64/libcap.so.2 (0x00007ff9c62ff000)
        	libc.so.6 => /lib64/libc.so.6 (0x00007ff9c6139000)
        	/lib64/ld-linux-x86-64.so.2 (0x00007ff9c6326000)
        $
      Signed-off-by: NIgor Lubashev <ilubashe@akamai.com>
      Acked-by: NJiri Olsa <jolsa@kernel.org>
      Tested-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
      Cc: Alexey Budankov <alexey.budankov@linux.intel.com>
      Cc: James Morris <jmorris@namei.org>
      Cc: Mathieu Poirier <mathieu.poirier@linaro.org>
      Cc: Namhyung Kim <namhyung@kernel.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Suzuki Poulouse <suzuki.poulose@arm.com>
      [ split from a larger patch ]
      Link: http://lkml.kernel.org/r/8a1e76cf5c7c9796d0d4d240fbaa85305298aafa.1565188228.git.ilubashe@akamai.comSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      74d5f3d0
  11. 30 7月, 2019 1 次提交
    • J
      libperf: Make libperf.a part of the perf build · 31435049
      Jiri Olsa 提交于
      Add an empty libperf.a under tools/perf/lib and link it with perf.
      
      It can also be built separately with:
      
        $ cd tools/perf/lib && make
          CC       core.o
          LD       libperf-in.o
          AR       libperf.a
          LINK     libperf.so
      
      Committer testing:
      
        $ make O=/tmp/build/perf -C tools/perf/lib/
        make: Entering directory '/home/acme/git/perf/tools/perf/lib'
          LINK     /tmp/build/perf/libperf.so
        make: Leaving directory '/home/acme/git/perf/tools/perf/lib'
        $ ls -la /tmp/build/perf/libperf.so
        -rwxrwxr-x. 1 acme acme 16232 Jul 22 15:30 /tmp/build/perf/libperf.so
        $ file /tmp/build/perf/libperf.so
        /tmp/build/perf/libperf.so: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, BuildID[sha1]=7a51d227d871b381ddb686dcf94145c4dd908221, not stripped
        $ git status tools/perf
        On branch perf/core
        nothing to commit, working tree clean
        $
        $ ls -lart tools/perf/lib/
        total 16
        drwxrwxr-x. 16 acme acme 4096 Jul 22 15:29 ..
        -rw-rw-r--.  1 acme acme 1633 Jul 22 15:29 Makefile
        -rw-rw-r--.  1 acme acme    0 Jul 22 15:29 core.c
        -rw-rw-r--.  1 acme acme   20 Jul 22 15:29 Build
        drwxrwxr-x.  2 acme acme 4096 Jul 22 15:29 .
        $
      
      Committer notes:
      
      Need to add -I$(srctree)/tools/arch/$(ARCH)/include/uapi
      -I$(srctree)/tools/include/uapi to tools/perf/lib/Makefile's INCLUDE
      variable to pick up the latest versions of kernel headers, even in older
      systems, this is in line with what is in tools/lib/bpf/Makefile.
      Signed-off-by: NJiri Olsa <jolsa@kernel.org>
      Tested-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
      Cc: Alexey Budankov <alexey.budankov@linux.intel.com>
      Cc: Andi Kleen <ak@linux.intel.com>
      Cc: Michael Petlan <mpetlan@redhat.com>
      Cc: Namhyung Kim <namhyung@kernel.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Link: http://lkml.kernel.org/r/20190721112506.12306-24-jolsa@kernel.orgSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      31435049
  12. 08 7月, 2019 1 次提交
    • A
      tools build: Check if gettid() is available before providing helper · 05c78468
      Arnaldo Carvalho de Melo 提交于
      Laura reported that the perf build failed in fedora when we got a glibc
      that provides gettid(), which I reproduced using fedora rawhide with the
      glibc-devel-2.29.9000-26.fc31.x86_64 package.
      
      Add a feature check to avoid providing a gettid() helper in such
      systems.
      
      On a fedora rawhide system with this patch applied we now get:
      
        [root@7a5f55352234 perf]# grep gettid /tmp/build/perf/FEATURE-DUMP
        feature-gettid=1
        [root@7a5f55352234 perf]# cat /tmp/build/perf/feature/test-gettid.make.output
        [root@7a5f55352234 perf]# ldd /tmp/build/perf/feature/test-gettid.bin
                linux-vdso.so.1 (0x00007ffc6b1f6000)
                libc.so.6 => /lib64/libc.so.6 (0x00007f04e0a74000)
                /lib64/ld-linux-x86-64.so.2 (0x00007f04e0c47000)
        [root@7a5f55352234 perf]# nm /tmp/build/perf/feature/test-gettid.bin | grep -w gettid
                         U gettid@@GLIBC_2.30
        [root@7a5f55352234 perf]#
      
      While on a fedora:29 system:
      
        [acme@quaco perf]$ grep gettid /tmp/build/perf/FEATURE-DUMP
        feature-gettid=0
        [acme@quaco perf]$ cat /tmp/build/perf/feature/test-gettid.make.output
        test-gettid.c: In function ‘main’:
        test-gettid.c:8:9: error: implicit declaration of function ‘gettid’; did you mean ‘getgid’? [-Werror=implicit-function-declaration]
          return gettid();
                 ^~~~~~
                 getgid
        cc1: all warnings being treated as errors
        [acme@quaco perf]$
      Reported-by: NLaura Abbott <labbott@redhat.com>
      Tested-by: NLaura Abbott <labbott@redhat.com>
      Acked-by: NJiri Olsa <jolsa@kernel.org>
      Cc: Adrian Hunter <adrian.hunter@intel.com>
      Cc: Florian Weimer <fweimer@redhat.com>
      Cc: Namhyung Kim <namhyung@kernel.org>
      Cc: Stephane Eranian <eranian@google.com>
      Link: https://lkml.kernel.org/n/tip-yfy3ch53agmklwu9o7rlgf9c@git.kernel.orgSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      05c78468
  13. 19 6月, 2019 1 次提交
    • A
      perf build: Handle slang being in /usr/include and in /usr/include/slang/ · 78d6ccce
      Arnaldo Carvalho de Melo 提交于
      In some distros slang.h may be in a /usr/include 'slang' subdir, so use
      the if slang is not explicitely disabled (by using NO_SLANG=1) and its
      feature test for the common case (having /usr/include/slang.h) failed,
      use the results for the test that checks if it is in slang/slang.h.
      
      Change the only file in perf that includes slang.h to use
      HAVE_SLANG_INCLUDE_SUBDIR and forget about this for good.
      
      On a rhel6 system now we have:
      
        $ /tmp/build/perf/perf -vv | grep slang
                      libslang: [ on  ]  # HAVE_SLANG_SUPPORT
        $ ldd /tmp/build/perf/perf | grep libslang
        	libslang.so.2 => /usr/lib64/libslang.so.2 (0x00007fa2d5a8d000)
        $ grep slang /tmp/build/perf/FEATURE-DUMP
        feature-libslang=0
        feature-libslang-include-subdir=1
        $ cat /etc/redhat-release
        CentOS release 6.10 (Final)
        $
      
      While on fedora:29:
      
        $ /tmp/build/perf/perf -vv | grep slang
                      libslang: [ on  ]  # HAVE_SLANG_SUPPORT
        $ ldd /tmp/build/perf/perf | grep slang
        	libslang.so.2 => /lib64/libslang.so.2 (0x00007f8eb11a7000)
        $ grep slang /tmp/build/perf/FEATURE-DUMP
        feature-libslang=1
        feature-libslang-include-subdir=1
        $
        $ cat /etc/fedora-release
        Fedora release 29 (Twenty Nine)
        $
      
      The feature-libslang-include-subdir=1 line is because the 'gettid()'
      test was added to test-all.c as the new glibc has an implementation for
      that, so we soon should have it not failing, i.e. should be the common
      case soon. Perhaps I should move it out till it becomes the norm...
      
      Cc: Adrian Hunter <adrian.hunter@intel.com>
      Cc: Florian Fainelli <f.fainelli@gmail.com>
      Cc: Jiri Olsa <jolsa@kernel.org>
      Cc: Namhyung Kim <namhyung@kernel.org>
      Fixes: 1955c8cf ("perf tools: Don't hardcode host include path for libslang")
      Link: https://lkml.kernel.org/n/tip-bkgtpsu3uit821fuwsdhj9gd@git.kernel.orgSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      78d6ccce
  14. 18 6月, 2019 2 次提交
    • F
      perf tools: Don't hardcode host include path for libslang · 1955c8cf
      Florian Fainelli 提交于
      Hardcoding /usr/include/slang is fundamentally incompatible with cross
      compilation and will lead to the inability for a cross-compiled
      environment to properly detect whether slang is available or not.
      
      If /usr/include/slang is necessary that is a distribution specific
      knowledge that could be solved with either a standard pkg-config .pc
      file (which slang has) or simply overriding CFLAGS accordingly, but the
      default perf Makefile should be clean of all of that.
      Signed-off-by: NFlorian Fainelli <f.fainelli@gmail.com>
      Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
      Cc: Alexey Budankov <alexey.budankov@linux.intel.com>
      Cc: bcm-kernel-feedback-list@broadcom.com
      Cc: Jakub Kicinski <jakub.kicinski@netronome.com>
      Cc: Jiri Olsa <jolsa@redhat.com>
      Cc: Namhyung Kim <namhyung@kernel.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Quentin Monnet <quentin.monnet@netronome.com>
      Cc: Stanislav Fomichev <sdf@google.com>
      Fixes: ef7b93a1 ("perf report: Librarize the annotation code and use it in the newt browser")
      Link: http://lkml.kernel.org/r/20190614183949.5588-1-f.fainelli@gmail.comSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      1955c8cf
    • A
      tools build: Check if gettid() is available before providing helper · 4541a8bb
      Arnaldo Carvalho de Melo 提交于
      Laura reported that the perf build failed in fedora when we got a glibc
      that provides gettid(), which I reproduced using fedora rawhide with the
      glibc-devel-2.29.9000-26.fc31.x86_64 package.
      
      Add a feature check to avoid providing a gettid() helper in such
      systems.
      
      On a fedora rawhide system with this patch applied we now get:
      
        [root@7a5f55352234 perf]# grep gettid /tmp/build/perf/FEATURE-DUMP
        feature-gettid=1
        [root@7a5f55352234 perf]# cat /tmp/build/perf/feature/test-gettid.make.output
        [root@7a5f55352234 perf]# ldd /tmp/build/perf/feature/test-gettid.bin
                linux-vdso.so.1 (0x00007ffc6b1f6000)
                libc.so.6 => /lib64/libc.so.6 (0x00007f04e0a74000)
                /lib64/ld-linux-x86-64.so.2 (0x00007f04e0c47000)
        [root@7a5f55352234 perf]# nm /tmp/build/perf/feature/test-gettid.bin | grep -w gettid
                         U gettid@@GLIBC_2.30
        [root@7a5f55352234 perf]#
      
      While on a fedora:29 system:
      
        [acme@quaco perf]$ grep gettid /tmp/build/perf/FEATURE-DUMP
        feature-gettid=0
        [acme@quaco perf]$ cat /tmp/build/perf/feature/test-gettid.make.output
        test-gettid.c: In function ‘main’:
        test-gettid.c:8:9: error: implicit declaration of function ‘gettid’; did you mean ‘getgid’? [-Werror=implicit-function-declaration]
          return gettid();
                 ^~~~~~
                 getgid
        cc1: all warnings being treated as errors
        [acme@quaco perf]$
      Reported-by: NLaura Abbott <labbott@redhat.com>
      Tested-by: NLaura Abbott <labbott@redhat.com>
      Acked-by: NJiri Olsa <jolsa@kernel.org>
      Cc: Adrian Hunter <adrian.hunter@intel.com>
      Cc: Florian Weimer <fweimer@redhat.com>
      Cc: Namhyung Kim <namhyung@kernel.org>
      Cc: Stephane Eranian <eranian@google.com>
      Link: https://lkml.kernel.org/n/tip-yfy3ch53agmklwu9o7rlgf9c@git.kernel.orgSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      4541a8bb
  15. 11 6月, 2019 1 次提交
  16. 21 5月, 2019 1 次提交
  17. 16 5月, 2019 1 次提交
  18. 09 5月, 2019 1 次提交
  19. 03 5月, 2019 1 次提交
    • A
      tools build: Add -ldl to the disassembler-four-args feature test · c638417e
      Arnaldo Carvalho de Melo 提交于
      Thomas Backlund reported that the perf build was failing on the Mageia 7
      distro, that is because it uses:
      
        cat /tmp/build/perf/feature/test-disassembler-four-args.make.output
        /usr/bin/ld: /usr/lib64/libbfd.a(plugin.o): in function `try_load_plugin':
        /home/iurt/rpmbuild/BUILD/binutils-2.32/objs/bfd/../../bfd/plugin.c:243:
        undefined reference to `dlopen'
        /usr/bin/ld:
        /home/iurt/rpmbuild/BUILD/binutils-2.32/objs/bfd/../../bfd/plugin.c:271:
        undefined reference to `dlsym'
        /usr/bin/ld:
        /home/iurt/rpmbuild/BUILD/binutils-2.32/objs/bfd/../../bfd/plugin.c:256:
        undefined reference to `dlclose'
        /usr/bin/ld:
        /home/iurt/rpmbuild/BUILD/binutils-2.32/objs/bfd/../../bfd/plugin.c:246:
        undefined reference to `dlerror'
        as we allow dynamic linking and loading
      
      Mageia 7 uses these linker flags:
        $ rpm --eval %ldflags
          -Wl,--as-needed -Wl,--no-undefined -Wl,-z,relro -Wl,-O1 -Wl,--build-id -Wl,--enable-new-dtags
      
      So add -ldl to this feature LDFLAGS.
      Reported-by: NThomas Backlund <tmb@mageia.org>
      Tested-by: NThomas Backlund <tmb@mageia.org>
      Cc: Adrian Hunter <adrian.hunter@intel.com>
      Cc: Jiri Olsa <jolsa@kernel.org>
      Cc: Namhyung Kim <namhyung@kernel.org>
      Cc: Song Liu <songliubraving@fb.com>
      Link: https://lkml.kernel.org/r/20190501173158.GC21436@kernel.orgSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      c638417e
  20. 02 4月, 2019 1 次提交
  21. 21 3月, 2019 1 次提交
    • S
      perf build: Check what binutils's 'disassembler()' signature to use · 8a1b1718
      Song Liu 提交于
      Commit 003ca0fd2286 ("Refactor disassembler selection") in the binutils
      repo, which changed the disassembler() function signature, so we must
      use the feature test introduced in fb982666 ("tools/bpftool: fix
      bpftool build with bintutils >= 2.9") to deal with that.
      
      Committer testing:
      
      After adding the missing function call to test-all.c, and:
      
        FEATURE_CHECK_LDFLAGS-disassembler-four-args = -bfd -lopcodes
      
      And the fallbacks for cases where we need -liberty and sometimes -lz to
      tools/perf/Makefile.config, we get:
      
        $ make -C tools/perf O=/tmp/build/perf install-bin
        make: Entering directory '/home/acme/git/perf/tools/perf'
          BUILD:   Doing 'make -j8' parallel build
      
        Auto-detecting system features:
        ...                         dwarf: [ on  ]
        ...            dwarf_getlocations: [ on  ]
        ...                         glibc: [ on  ]
        ...                          gtk2: [ on  ]
        ...                      libaudit: [ on  ]
        ...                        libbfd: [ on  ]
        ...                        libelf: [ on  ]
        ...                       libnuma: [ on  ]
        ...        numa_num_possible_cpus: [ on  ]
        ...                       libperl: [ on  ]
        ...                     libpython: [ on  ]
        ...                      libslang: [ on  ]
        ...                     libcrypto: [ on  ]
        ...                     libunwind: [ on  ]
        ...            libdw-dwarf-unwind: [ on  ]
        ...                          zlib: [ on  ]
        ...                          lzma: [ on  ]
        ...                     get_cpuid: [ on  ]
        ...                           bpf: [ on  ]
        ...                        libaio: [ on  ]
        ...        disassembler-four-args: [ on  ]
          CC       /tmp/build/perf/jvmti/libjvmti.o
          CC       /tmp/build/perf/builtin-bench.o
        <SNIP>
        $
        $
      
      The feature detection test-all.bin gets successfully built and linked:
      
        $ ls -la /tmp/build/perf/feature/test-all.bin
        -rwxrwxr-x. 1 acme acme 2680352 Mar 19 11:07 /tmp/build/perf/feature/test-all.bin
        $ nm /tmp/build/perf/feature/test-all.bin  | grep -w disassembler
        0000000000061f90 T disassembler
        $
      
      Time to move on to the patches that make use of this disassembler()
      routine in binutils's libopcodes.
      Signed-off-by: NSong Liu <songliubraving@fb.com>
      Tested-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      Cc: Alexei Starovoitov <ast@kernel.org>
      Cc: Daniel Borkmann <daniel@iogearbox.net>
      Cc: Jakub Kicinski <jakub.kicinski@netronome.com>
      Cc: Jiri Olsa <jolsa@kernel.org>
      Cc: Namhyung Kim <namhyung@kernel.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Roman Gushchin <guro@fb.com>
      Cc: Stanislav Fomichev <sdf@google.com>
      Link: http://lkml.kernel.org/r/20190312053051.2690567-13-songliubraving@fb.com
      [ split from a larger patch, added missing FEATURE_CHECK_LDFLAGS-disassembler-four-args ]
      Signed-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      8a1b1718
  22. 20 3月, 2019 1 次提交
  23. 15 2月, 2019 4 次提交
    • A
      perf build: Add missing FEATURE_CHECK_LDFLAGS-libcrypto · 271402a3
      Arnaldo Carvalho de Melo 提交于
      When the libcrypto feature test was added we forgot to add its
      FEATURE_CHECK_LDFLAGS pointing to the library needed to link with the
      test-all.bin feature test fast path binary, so even when it was
      introduced we got this:
      
        $ cat /tmp/build/perf/feature/test-all.make.output
        /usr/bin/ld: /tmp/ccjKeJJU.o: in function `main_test_libcrypto':
        /home/acme/git/perf/tools/build/feature/test-libcrypto.c:10: undefined reference to `MD5_Init'
        /usr/bin/ld: /home/acme/git/perf/tools/build/feature/test-libcrypto.c:11: undefined reference to `MD5_Update'
        /usr/bin/ld: /home/acme/git/perf/tools/build/feature/test-libcrypto.c:12: undefined reference to `MD5_Final'
        /usr/bin/ld: /home/acme/git/perf/tools/build/feature/test-libcrypto.c:14: undefined reference to `SHA1'
        collect2: error: ld returned 1 exit status
        $ cat /tmp/build/perf/feature/test-libcrypto.
        test-libcrypto.bin          test-libcrypto.d            test-libcrypto.make.output
        $ cat /tmp/build/perf/feature/test-libcrypto.make.output
        $
      
      Fix it, so that we keep the fast path, which, at this point, will fail
      with the unwind-ARCH feature tests, that will be fixed in a followup
      patch:
      
        $ make -C tools/perf O=/tmp/build/perf
        ...                     libcrypto: [ on  ]
         <SNIP>
        $ cat /tmp/build/perf/feature/test-all.make.output
        $ ldd /tmp/build/perf/feature/test-all.bin | grep libcrypto
      	libcrypto.so.1.1 => /lib64/libcrypto.so.1.1 (0x00007f9892805000)
        $
        $ grep libcrypto /tmp/build/perf/FEATURE-DUMP
        feature-libcrypto=1
        $
      
      With the unwind-ARCH tests fixed, we now finally manage to get
      test-all.bin built and linked with the features it tests, among them the
      ones fixed in this patchkit:
      
        $ ldd /tmp/build/perf/feature/test-all.bin  | egrep 'unwind|crypto'
      	libcrypto.so.1.1 => /lib64/libcrypto.so.1.1 (0x00007f95cf2b8000)
      	libunwind-x86_64.so.8 => /lib64/libunwind-x86_64.so.8 (0x00007f95cf294000)
      	libunwind.so.8 => /lib64/libunwind.so.8 (0x00007f95cf278000)
        $
      
      Cc: Adrian Hunter <adrian.hunter@intel.com>
      Cc: Andi Kleen <ak@linux.intel.com>
      Cc: Carl Love <cel@us.ibm.com>
      Cc: David Ahern <dsahern@gmail.com>
      Cc: Jiri Olsa <jolsa@kernel.org>
      Cc: John McCutchan <johnmccutchan@google.com>
      Cc: Namhyung Kim <namhyung@kernel.org>
      Cc: Pawel Moll <pawel.moll@arm.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Sonny Rao <sonnyrao@chromium.org>
      Cc: Stephane Eranian <eranian@google.com>
      Cc: Sukadev Bhattiprolu <sukadev@linux.vnet.ibm.com>
      Fixes: 8ee46460 ("perf build: Add libcrypto feature detection")
      Link: https://lkml.kernel.org/n/tip-rexc248jorf5b4l3qjn888cz@git.kernel.orgSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      271402a3
    • A
      perf unwind: Do not put libunwind-{x86,aarch64} in FEATURE_TESTS_BASIC · 5c4d7c82
      Arnaldo Carvalho de Melo 提交于
      As it is not normally available on x86_64 not being tested on test-all.c
      but being in FEATURE_TESTS_BASIC ends up implying that those features
      are present, which leads to trying to link with those libraries and a
      build failure now that test-all.c is finally again building
      successfully:
      
        /usr/bin/ld: cannot find -lunwind-x86
        /usr/bin/ld: cannot find -lunwind-aarch64
        collect2: error: ld returned 1 exit status
        make[3]: *** [Makefile:199: /tmp/build/perf/plugin_jbd2.so] Error 1
        make[3]: *** Waiting for unfinished jobs....
        /usr/bin/ld: cannot find -lunwind-x86
        /usr/bin/ld: cannot find -lunwind-aarch64
      
      So remove those features from there and explicitely test them.
      
      And then move this patch to just before the last one that allows this to
      be exposed, so that we keep the tree bisectable.
      
      With all this in place we get, at this point:
      
        $ ldd /tmp/build/perf/feature/test-libunwind.bin
      	linux-vdso.so.1 (0x00007fffa09c6000)
      	libunwind-x86_64.so.8 => /lib64/libunwind-x86_64.so.8 (0x00007fbcf4451000)
      	libunwind.so.8 => /lib64/libunwind.so.8 (0x00007fbcf4435000)
      	liblzma.so.5 => /lib64/liblzma.so.5 (0x00007fbcf440c000)
      	libelf.so.1 => /lib64/libelf.so.1 (0x00007fbcf43f2000)
      	libc.so.6 => /lib64/libc.so.6 (0x00007fbcf422c000)
      	libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007fbcf4211000)
      	/lib64/ld-linux-x86-64.so.2 (0x00007fbcf4491000)
      	libpthread.so.0 => /lib64/libpthread.so.0 (0x00007fbcf41ed000)
      	libz.so.1 => /lib64/libz.so.1 (0x00007fbcf41d3000)
        $ cat /tmp/build/perf/feature/test-libunwind-x86.make.output
        test-libunwind-x86.c:2:10: fatal error: libunwind-x86.h: No such file or directory
         #include <libunwind-x86.h>
                  ^~~~~~~~~~~~~~~~~
        compilation terminated.
        $ cat /tmp/build/perf/feature/test-libunwind-aarch64.make.output
        test-libunwind-aarch64.c:2:10: fatal error: libunwind-aarch64.h: No such file or directory
        #include <libunwind-aarch64.h>
                 ^~~~~~~~~~~~~~~~~~~~~
        compilation terminated.
        $
        $ ldd ~/bin/perf | grep unwind
      	libunwind-x86_64.so.8 => /lib64/libunwind-x86_64.so.8 (0x00007f5ceb24b000)
      	libunwind.so.8 => /lib64/libunwind.so.8 (0x00007f5ceb22f000)
        $
      
      Cc: Adrian Hunter <adrian.hunter@intel.com>
      Cc: He Kuang <hekuang@huawei.com>
      Cc: Jean Pihet <jean.pihet@linaro.org>
      Cc: Jiri Olsa <jolsa@kernel.org>
      Cc: Namhyung Kim <namhyung@kernel.org>
      Cc: Wang Nan <wangnan0@huawei.com>
      Cc: Will Deacon <will.deacon@arm.com>
      Link: https://lkml.kernel.org/n/tip-vs6kwqsvwk7oxhs6z9mq87pp@git.kernel.orgSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      5c4d7c82
    • A
      perf coresight: Do not test for libopencsd by default · 1c3b28fd
      Arnaldo Carvalho de Melo 提交于
      Since it is not yet that generally available, avoid testing for the
      presence of libcoresight in the fast path test-all.bin feature test.
      
        # dnf search opencsd
        No matches found.
        # dnf search OpenCSD
        No matches found.
        # cat /etc/fedora-release
        Fedora release 29 (Twenty Nine)
        #
      
      I.e. right now, in my system test-all.bin is failing all the time since
      Fedora29 doesn't have libopencsd available:
      
        $ cat /tmp/build/perf/feature/test-all.make.output
        In file included from test-all.c:174:
        test-libopencsd.c:2:10: fatal error: opencsd/c_api/opencsd_c_api.h: No such file or directory
         #include <opencsd/c_api/opencsd_c_api.h>
                  ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
        compilation terminated.
      
      See:
      
        6ab2b762 ("perf build: Disable libbabeltrace check by default")
      
      For the rationale, as soon as libopencsd becomes more generally packaged
      and available, we do the same thing we did with babeltrace, enabling it
      by default, as done in:
      
        24787afb ("perf tools: Enable LIBBABELTRACE by default")
      
      For now, to explicitely ask for opencsd, make sure you have it installed
      and use:
      
         make -C tools/perf CORESIGHT=1
      
      The feature test output will be there as an empty file:
      
        $ ls -la /tmp/build/perf/feature/test-libopencsd.make.output
      
      Because the binary used for the feature check was successfully built:
      
        $ ls -la /tmp/build/perf/feature/test-libopencsd.bin
        -rwxrwxr-x. 1 acme acme 18336 Feb 12 14:49 /tmp/build/perf/feature/test-libopencsd.bin
        $ ldd /tmp/build/perf/feature/test-libopencsd.bin
      	linux-vdso.so.1 (0x00007fffe18cc000)
      	libopencsd_c_api.so.0 => /lib64/libopencsd_c_api.so.0 (0x00007fb8e67f6000)
      	libopencsd.so.0 => /lib64/libopencsd.so.0 (0x00007fb8e676f000)
      	libc.so.6 => /lib64/libc.so.6 (0x00007fb8e65a9000)
      	libstdc++.so.6 => /lib64/libstdc++.so.6 (0x00007fb8e6411000)
      	libm.so.6 => /lib64/libm.so.6 (0x00007fb8e628d000)
      	libgcc_s.so.1 => /lib64/libgcc_s.so.1 (0x00007fb8e6272000)
      	/lib64/ld-linux-x86-64.so.2 (0x00007fb8e6828000)
        $
      
      And the resulting perf binary will be linked with it:
      
        -rw-rw-r--. 1 acme acme 0 Feb 12 14:49 /tmp/build/perf/feature/test-libopencsd.make.output
        $ ldd ~/bin/perf | grep opencsd
      	libopencsd_c_api.so.0 => /lib64/libopencsd_c_api.so.0 (0x00007fd43097f000)
      	libopencsd.so.0 => /lib64/libopencsd.so.0 (0x00007fd4308f8000)
        $
      
      To make sure this gets built before pushing things upstream I have a
      ubuntu:19.04-x-arm64 container that has:
      
        [root@quaco x-arm64]# grep CORESIGHT Dockerfile
        ENV EXTRA_MAKE_ARGS=CORESIGHT=1
        [root@quaco x-arm64]#
      
      So that I always build with libopencsd before pushing things upstream.
      
      Cc: Adrian Hunter <adrian.hunter@intel.com>
      Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
      Cc: Jiri Olsa <jolsa@kernel.org>
      Cc: Kim Phillips <kim.phillips@arm.com>
      Cc: linux-arm-kernel@lists.infradead.org
      Cc: Mathieu Poirier <mathieu.poirier@linaro.org>
      Cc: Mike Leach <mike.leach@arm.com>
      Cc: Namhyung Kim <namhyung@kernel.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Suzuki Poulouse <suzuki.poulose@arm.com>
      Link: https://lkml.kernel.org/n/tip-20vyy39jw9jgrijesi30fgox@git.kernel.orgSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      1c3b28fd
    • A
      tools build: Add -lrt to FEATURE_CHECK_LDFLAGS-libaio · aa8f9c51
      Arnaldo Carvalho de Melo 提交于
      Since we need it to resolve the AIO symbols, otherwise we fail with:
      
        $ cat /tmp/build/perf/feature/test-all.make.output
        /usr/bin/ld: /tmp/ccEqrj36.o: undefined reference to symbol 'aio_return64@@GLIBC_2.2.5'
        /usr/bin/ld: //usr/lib64/librt.so.1: error adding symbols: DSO missing from command line
        collect2: error: ld returned 1 exit status
        $
      
      When we added the aio support in 'perf record' only the test-libaio.bin
      target got the -lrt, i.e. the feature detection slow path. Fix it.
      
      Cc: Adrian Hunter <adrian.hunter@intel.com>
      Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
      Cc: Alexey Budankov <alexey.budankov@linux.intel.com>
      Cc: Andi Kleen <ak@linux.intel.com>
      Cc: Jiri Olsa <jolsa@kernel.org>
      Cc: Namhyung Kim <namhyung@kernel.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Fixes: 2a07d814 ("tools build feature: Check if libaio is available")
      Signed-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      aa8f9c51
  24. 21 12月, 2018 1 次提交
    • S
      perf build: Don't unconditionally link the libbfd feature test to -liberty and -lz · 14541b1e
      Stanislav Fomichev 提交于
      Current libbfd feature test unconditionally links against -liberty and -lz.
      While it's required on some systems (e.g. opensuse), it's completely
      unnecessary on the others, where only -lbdf is sufficient (debian).
      This patch streamlines (and renames) the following feature checks:
      
      feature-libbfd           - only link against -lbfd (debian),
                                 see commit 2cf90407 ("perf tools: Fix bfd
      			   dependency libraries detection")
      feature-libbfd-liberty   - link against -lbfd and -liberty
      feature-libbfd-liberty-z - link against -lbfd, -liberty and -lz (opensuse),
                                 see commit 280e7c48 ("perf tools: fix BFD
      			   detection on opensuse")
      
      (feature-liberty{,-z} were renamed to feature-libbfd-liberty{,z}
      for clarity)
      
      The main motivation is to fix this feature test for bpftool which is
      currently broken on debian (libbfd feature shows OFF, but we still
      unconditionally link against -lbfd and it works).
      
      Tested on debian with only -lbfd installed (without -liberty); I'd
      appreciate if somebody on the other systems can test this new detection
      method.
      Signed-off-by: NStanislav Fomichev <sdf@google.com>
      Acked-by: NJiri Olsa <jolsa@kernel.org>
      Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
      Cc: Mathieu Poirier <mathieu.poirier@linaro.org>
      Cc: Namhyung Kim <namhyung@kernel.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Link: http://lkml.kernel.org/r/4dfc634cfcfb236883971b5107cf3c28ec8a31be.1542328222.git.sdf@google.comSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      14541b1e
  25. 18 12月, 2018 4 次提交
  26. 22 11月, 2018 2 次提交
    • J
      perf jvmti: Separate jvmti cmlr check · dd1d0044
      Jiri Olsa 提交于
      The Compiled Method Load Record (cmlr) is JDK specific interface to
      access JVM stack info. This makes the jvmti agent code not compile under
      another jdk, which does not support that.
      
      Separating jvmti cmlr check into special feature check, and adding
      HAVE_JVMTI_CMLR macro to indicate that.
      
      Mark cmlr code in jvmti/libjvmti.c with HAVE_JVMTI_CMLR, so we can
      compile it on system without cmlr support.
      
      This change makes the jvmti compile with java-1.8.0-ibm package. It's
      without the line numbers support, but the rest works.
      
      Adding NO_JVMTI_CMLR compile variable for testing.
      Signed-off-by: NJiri Olsa <jolsa@kernel.org>
      Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
      Cc: Ben Gainey <ben.gainey@arm.com>
      Cc: Gustavo Luiz Duarte <gduarte@redhat.com>
      Cc: Namhyung Kim <namhyung@kernel.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Stephane Eranian <eranian@google.com>
      Link: http://lkml.kernel.org/r/20181121154341.21521-1-jolsa@kernel.orgSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      dd1d0044
    • A
      tools build feature: Check if eventfd() is available · 11c6cbe7
      Arnaldo Carvalho de Melo 提交于
      A new 'perf bench epoll' will use this, and to disable it for older
      systems, add a feature test for this API.
      
      This is just a simple program that if successfully compiled, means that
      the feature is present, at least at the library level, in a build that
      sets the output directory to /tmp/build/perf (using O=/tmp/build/perf),
      we end up with:
      
        $ ls -la /tmp/build/perf/feature/test-eventfd*
        -rwxrwxr-x. 1 acme acme 8176 Nov 21 15:58 /tmp/build/perf/feature/test-eventfd.bin
        -rw-rw-r--. 1 acme acme  588 Nov 21 15:58 /tmp/build/perf/feature/test-eventfd.d
        -rw-rw-r--. 1 acme acme    0 Nov 21 15:58 /tmp/build/perf/feature/test-eventfd.make.output
        $ ldd /tmp/build/perf/feature/test-eventfd.bin
      	  linux-vdso.so.1 (0x00007fff3bf3f000)
      	  libc.so.6 => /lib64/libc.so.6 (0x00007fa984061000)
      	  /lib64/ld-linux-x86-64.so.2 (0x00007fa984417000)
        $ grep eventfd -A 2 -B 2 /tmp/build/perf/FEATURE-DUMP
        feature-dwarf=1
        feature-dwarf_getlocations=1
        feature-eventfd=1
        feature-fortify-source=1
        feature-sync-compare-and-swap=1
        $
      
      The main thing here is that in the end we'll have -DHAVE_EVENTFD in
      CFLAGS, and then the 'perf bench' entry needing that API can be
      selectively pruned.
      
      Cc: Adrian Hunter <adrian.hunter@intel.com>
      Cc: Andrew Morton <akpm@linux-foundation.org>
      Cc: David Ahern <dsahern@gmail.com>
      Cc: Davidlohr Bueso <dbueso@suse.de>
      Cc: Jason Baron <jbaron@akamai.com>
      Cc: Jiri Olsa <jolsa@kernel.org>
      Cc: Namhyung Kim <namhyung@kernel.org>
      Cc: Wang Nan <wangnan0@huawei.com>
      Link: https://lkml.kernel.org/n/tip-wkeldwob7dpx6jvtuzl8164k@git.kernel.orgSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      11c6cbe7
  27. 20 11月, 2018 1 次提交
  28. 16 10月, 2018 1 次提交
    • J
      perf tools: Fix use of alternatives to find JDIR · 36b8d462
      Jarod Wilson 提交于
      When a build is run from something like a cron job, the user's $PATH is
      rather minimal, of note, not including /usr/sbin in my own case. Because
      of that, an automated rpm package build ultimately fails to find
      libperf-jvmti.so, because somewhere within the build, this happens...
      
        /bin/sh: alternatives: command not found
        /bin/sh: alternatives: command not found
        Makefile.config:849: No openjdk development package found, please install
        JDK package, e.g. openjdk-8-jdk, java-1.8.0-openjdk-devel
      
      ...and while the build continues, libperf-jvmti.so isn't built, and
      things fall down when rpm tries to find all the %files specified. Exact
      same system builds everything just fine when the job is launched from a
      login shell instead of a cron job, since alternatives is in $PATH, so
      openjdk is actually found.
      
      The test required to get into this section of code actually specifies
      the full path, as does a block just above it, so let's do that here too.
      Signed-off-by: NJarod Wilson <jarod@redhat.com>
      Acked-by: NJiri Olsa <jolsa@redhat.com>
      Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
      Cc: Namhyung Kim <namhyung@kernel.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Stephane Eranian <eranian@google.com>
      Cc: William Cohen <wcohen@redhat.com>
      Fixes: d4dfdf00 ("perf jvmti: Plug compilation into perf build")
      Link: http://lkml.kernel.org/r/20180906221812.11167-1-jarod@redhat.comSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      36b8d462
  29. 31 7月, 2018 1 次提交
    • T
      perf build: Fix installation directory for eBPF · 83868bf7
      Thomas Richter 提交于
      The perf tool build and install is controlled via a Makefile. The
      'install' rule creates directories and copies files. Among them are
      header files installed in /usr/lib/include/perf/bpf/.
      
      However all listed examples are installing its header files in
      
        /usr/lib/<tool-name>/...[/include]/header.h
      
      and not in
      
        /usr/lib/include/<tool-name>/.../header.h.
      
      Background information:
      
      Building the Fedora 28 glibc RPM on s390x and s390 fails on s390 (gcc
      -m31) as gcc is not able to find header-files like stdbool.h.
      
      In the glibc.spec file, you can see that glibc is configured with
      "--with-headers". In this case, first -nostdinc is added to the CFLAGS
      and then further include paths are added via -isystem.  One of those
      paths should contain header files like stdbool.h.
      
      In order to get this path, gcc is invoked with:
      
      - on Fedora 28 (with 4.18 kernel):
      
        $ gcc -print-file-name=include
        /usr/lib/gcc/s390x-redhat-linux/8/include
        $ gcc -m31 -print-file-name=include
        /usr/lib/gcc/s390x-redhat-linux/8/../../../../lib/include
        => If perf is installed, this is: /usr/lib/include
        On my machine this directory is only containing the directory "perf".
        If perf is not installed gcc returns: /usr/lib/gcc/s390x-redhat-linux/8/include
      
      - on Ubuntu 18.04 (with 4.15 kernel):
      
        $ gcc  -print-file-name=include
        /usr/lib/gcc/s390x-linux-gnu/7/include
        $ gcc -m31 -print-file-name=include
        /usr/lib/gcc/s390x-linux-gnu/7/include
        => gcc returns the correct path even if perf is installed.
      
      In each case, the introduction of the subdirectory /usr/lib/include
      leads to the regression that one can not build the glibc RPM for s390
      anymore as gcc can not find headers like stdbool.h.
      
      To remedy this install bpf.h to /usr/lib/perf/include/bpf/bpf.h
      
      Output before using the command 'perf test -Fv 40':
      
        echo '...[bpf-program-source]...' | /usr/bin/clang ... \
      		   -I/root/lib/include/perf/bpf ...
                                     ^^^^^^^^^^^^
      ...
        [root@p23lp27 perf]# perf test -F 40
        40: BPF filter                                            :
        40.1: Basic BPF filtering                                 : Ok
        40.2: BPF pinning                                         : Ok
        40.3: BPF prologue generation                             : Ok
        40.4: BPF relocation checker                              : Ok
        [root@p23lp27 perf]#
      
      Output after using command 'perf test -Fv 40':
      
        echo '...[bpf-program-source]...' | /usr/bin/clang ... \
      		 -I/root/lib/perf/include/bpf ...
                                   ^^^^^^^^^^^^
      ...
        [root@p23lp27 perf]# perf test -F 40
        40: BPF filter                                            :
        40.1: Basic BPF filtering                                 : Ok
        40.2: BPF pinning                                         : Ok
        40.3: BPF prologue generation                             : Ok
        40.4: BPF relocation checker                              : Ok
        [root@p23lp27 perf]#
      
      Committer testing:
      
      While the above 'perf test -F 40' (or 'perf test bpf') will allow us
      to see that the correct path is now added via -I, to actually test this
      we better try to use a bpf script that includes files in the changed
      directory.
      
      We have the files that now reside in /root/lib/perf/examples/bpf/ to do
      just that:
      
        # tail -8 /root/lib/perf/examples/bpf/5sec.c
        #include <bpf.h>
      
        int probe(hrtimer_nanosleep, rqtp->tv_sec)(void *ctx, int err, long sec)
        {
      	  return sec == 5;
        }
      
        license(GPL);
        # perf trace -e *sleep -e /root/lib/perf/examples/bpf/5sec.c sleep 4
             0.333 (4000.086 ms): sleep/9248 nanosleep(rqtp: 0x7ffc155f3300) = 0
        # perf trace -e *sleep -e /root/lib/perf/examples/bpf/5sec.c sleep 5
             0.287 (         ): sleep/9659 nanosleep(rqtp: 0x7ffeafe38200) ...
             0.290 (         ): perf_bpf_probe:hrtimer_nanosleep:(ffffffff9911efe0) tv_sec=5
             0.287 (5000.059 ms): sleep/9659  ... [continued]: nanosleep()) = 0
        # perf trace -e *sleep -e /root/lib/perf/examples/bpf/5sec.c sleep 6
             0.247 (5999.951 ms): sleep/10068 nanosleep(rqtp: 0x7fff2086d900) = 0
        # perf trace -e *sleep -e /root/lib/perf/examples/bpf/5sec.c sleep 5.987
             0.293 (         ): sleep/10489 nanosleep(rqtp: 0x7ffdd4fc10e0) ...
             0.296 (         ): perf_bpf_probe:hrtimer_nanosleep:(ffffffff9911efe0) tv_sec=5
             0.293 (5986.912 ms): sleep/10489  ... [continued]: nanosleep()) = 0
        #
      Suggested-by: NStefan Liebler <stli@linux.ibm.com>
      Suggested-by: NArnaldo Carvalho de Melo <acme@kernel.org>
      Signed-off-by: NThomas Richter <tmricht@linux.ibm.com>
      Reviewed-by: NHendrik Brueckner <brueckner@linux.ibm.com>
      Tested-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      Cc: Heiko Carstens <heiko.carstens@de.ibm.com>
      Cc: Martin Schwidefsky <schwidefsky@de.ibm.com>
      Fixes: 1b16fffa ("perf llvm-utils: Add bpf include path to clang command line")
      Link: http://lkml.kernel.org/r/20180731073254.91090-1-tmricht@linux.ibm.comSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      83868bf7
  30. 25 7月, 2018 1 次提交
  31. 11 7月, 2018 1 次提交
    • J
      perf tools: Use python-config --includes rather than --cflags · 32aa928a
      Jeremy Cline 提交于
      Builds started failing in Fedora on Python 3.7 with:
      
          `.gnu.debuglto_.debug_macro' referenced in section
          `.gnu.debuglto_.debug_macro' of
          util/scripting-engines/trace-event-python.o: defined in discarded
          section
      
      In Fedora, Python 3.7 added -flto to the list of --cflags and since it
      was only applied to util/scripting-engines/trace-event-python.c and
      scripts/python/Perf-Trace-Util/Context.c, linking failed.
      
      It's not the first time the addition of flags has broken builds: commit
      c6707fde ("perf tools: Fix up build in hardnened environments")
      appears to have fixed a similar problem. "python-config --includes"
      provides the proper -I flags and doesn't introduce additional CFLAGS.
      Signed-off-by: NJeremy Cline <jcline@redhat.com>
      Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
      Cc: Jiri Olsa <jolsa@redhat.com>
      Cc: Namhyung Kim <namhyung@kernel.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Link: http://lkml.kernel.org/r/20180710154612.6285-1-jcline@redhat.comSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      32aa928a