1. 09 10月, 2018 1 次提交
    • J
      Revert "perf tools: Fix PMU term format max value calculation" · 1b9caa10
      Jiri Olsa 提交于
      This reverts commit ac0e2cd5.
      
      Michael reported an issue with oversized terms values assignment
      and I noticed there was actually a misunderstanding of the max
      value check in the past.
      
      The above commit's changelog says:
      
        If bit 21 is set, there is parsing issues as below.
      
          $ perf stat -a -e uncore_qpi_0/event=0x200002,umask=0x8/
          event syntax error: '..pi_0/event=0x200002,umask=0x8/'
                                            \___ value too big for format, maximum is 511
      
      But there's no issue there, because the event value is distributed
      along the value defined by the format. Even if the format defines
      separated bit, the value is treated as a continual number, which
      should follow the format definition.
      
      In above case it's 9-bit value with last bit separated:
        $ cat uncore_qpi_0/format/event
        config:0-7,21
      
      Hence the value 0x200002 is correctly reported as format violation,
      because it exceeds 9 bits. It should have been 0x102 instead, which
      sets the 9th bit - the bit 21 of the format.
      
        $ perf stat -vv -a -e uncore_qpi_0/event=0x102,umask=0x8/
        Using CPUID GenuineIntel-6-2D
        ...
        ------------------------------------------------------------
        perf_event_attr:
          type                             10
          size                             112
          config                           0x200802
          sample_type                      IDENTIFIER
        ...
      Reported-by: NMichael Petlan <mpetlan@redhat.com>
      Signed-off-by: NJiri Olsa <jolsa@kernel.org>
      Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
      Cc: Andi Kleen <ak@linux.intel.com>
      Cc: Kan Liang <kan.liang@linux.intel.com>
      Cc: Namhyung Kim <namhyung@kernel.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Fixes: ac0e2cd5 ("perf tools: Fix PMU term format max value calculation")
      Link: http://lkml.kernel.org/r/20181003072046.29276-1-jolsa@kernel.orgSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      1b9caa10
  2. 05 10月, 2018 2 次提交
    • M
      perf record: Use unmapped IP for inline callchain cursors · 7a8a8fcf
      Milian Wolff 提交于
      Only use the mapped IP to find inline frames, but keep using the
      unmapped IP for the callchain cursor. This ensures we properly show the
      unmapped IP when displaying a frame we received via the
      dso__parse_addr_inlines API for a module which does not contain
      sufficient debug symbols to show the srcline.
      
      This is another follow-up to commit 19610184 ("perf script: Show
      virtual addresses instead of offsets").
      Signed-off-by: NMilian Wolff <milian.wolff@kdab.com>
      Acked-by: NJiri Olsa <jolsa@kernel.org>
      Tested-by: NRavi Bangoria <ravi.bangoria@linux.ibm.com>
      Tested-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      Cc: Jin Yao <yao.jin@linux.intel.com>
      Cc: Namhyung Kim <namhyung@kernel.org>
      Cc: Sandipan Das <sandipan@linux.ibm.com>
      Fixes: 19610184 ("perf script: Show virtual addresses instead of offsets")
      Link: http://lkml.kernel.org/r/20180926135207.30263-2-milian.wolff@kdab.com
      Link: http://lkml.kernel.org/r/20181002073949.3297-1-milian.wolff@kdab.com
      [ Squashed a fix from Milian for a problem reported by Ravi, fixed up space damage ]
      Signed-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      7a8a8fcf
    • A
      perf python: Use -Wno-redundant-decls to build with PYTHON=python3 · 05a2f546
      Arnaldo Carvalho de Melo 提交于
      When building in ClearLinux using 'make PYTHON=python3' with gcc 8.2.1
      it fails with:
      
          GEN      /tmp/build/perf/python/perf.so
        In file included from /usr/include/python3.7m/Python.h:126,
                         from /git/linux/tools/perf/util/python.c:2:
        /usr/include/python3.7m/import.h:58:24: error: redundant redeclaration of ‘_PyImport_AddModuleObject’ [-Werror=redundant-decls]
         PyAPI_FUNC(PyObject *) _PyImport_AddModuleObject(PyObject *, PyObject *);
                                ^~~~~~~~~~~~~~~~~~~~~~~~~
        /usr/include/python3.7m/import.h:47:24: note: previous declaration of ‘_PyImport_AddModuleObject’ was here
         PyAPI_FUNC(PyObject *) _PyImport_AddModuleObject(PyObject *name,
                                ^~~~~~~~~~~~~~~~~~~~~~~~~
        cc1: all warnings being treated as errors
        error: command 'gcc' failed with exit status 1
      
      And indeed there is a redundant declaration in that Python.h file, one
      with parameter names and the other without, so just add
      -Wno-error=redundant-decls to the python setup instructions.
      
      Now perf builds with gcc in ClearLinux with the following Dockerfile:
      
        # docker.io/acmel/linux-perf-tools-build-clearlinux:latest
        FROM docker.io/clearlinux:latest
        MAINTAINER Arnaldo Carvalho de Melo <acme@kernel.org>
        RUN swupd update && \
            swupd bundle-add sysadmin-basic-dev
        RUN mkdir -m 777 -p /git /tmp/build/perf /tmp/build/objtool /tmp/build/linux && \
            groupadd -r perfbuilder && \
            useradd -m -r -g perfbuilder perfbuilder && \
            chown -R perfbuilder.perfbuilder /tmp/build/ /git/
        USER perfbuilder
        COPY rx_and_build.sh /
        ENV EXTRA_MAKE_ARGS=PYTHON=python3
        ENTRYPOINT ["/rx_and_build.sh"]
      
      Now to figure out why the build fails with clang, that is present in the
      above container as detected by the rx_and_build.sh script:
      
        clang version 6.0.1 (tags/RELEASE_601/final)
        Target: x86_64-unknown-linux-gnu
        Thread model: posix
        InstalledDir: /usr/sbin
        make: Entering directory '/git/linux/tools/perf'
          BUILD:   Doing 'make -j4' parallel build
          HOSTCC   /tmp/build/perf/fixdep.o
          HOSTLD   /tmp/build/perf/fixdep-in.o
          LINK     /tmp/build/perf/fixdep
      
        Auto-detecting system features:
        ...                         dwarf: [ OFF ]
        ...            dwarf_getlocations: [ OFF ]
        ...                         glibc: [ OFF ]
        ...                          gtk2: [ OFF ]
        ...                      libaudit: [ OFF ]
        ...                        libbfd: [ OFF ]
        ...                        libelf: [ OFF ]
        ...                       libnuma: [ OFF ]
        ...        numa_num_possible_cpus: [ OFF ]
        ...                       libperl: [ OFF ]
        ...                     libpython: [ OFF ]
        ...                      libslang: [ OFF ]
        ...                     libcrypto: [ OFF ]
        ...                     libunwind: [ OFF ]
        ...            libdw-dwarf-unwind: [ OFF ]
        ...                          zlib: [ OFF ]
        ...                          lzma: [ OFF ]
        ...                     get_cpuid: [ OFF ]
        ...                           bpf: [ OFF ]
      
        Makefile.config:331: *** No gnu/libc-version.h found, please install glibc-dev[el].  Stop.
        make[1]: *** [Makefile.perf:206: sub-make] Error 2
        make: *** [Makefile:70: all] Error 2
        make: Leaving directory '/git/linux/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: Thiago Macieira <thiago.macieira@intel.com>
      Cc: Wang Nan <wangnan0@huawei.com>
      Link: https://lkml.kernel.org/n/tip-c3khb9ac86s00qxzjrueomme@git.kernel.orgSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      05a2f546
  3. 28 9月, 2018 1 次提交
    • M
      perf report: Don't try to map ip to invalid map · ff4ce288
      Milian Wolff 提交于
      Fixes a crash when the report encounters an address that could not be
      associated with an mmaped region:
      
        #0  0x00005555557bdc4a in callchain_srcline (ip=<error reading variable: Cannot access memory at address 0x38>, sym=0x0, map=0x0) at util/machine.c:2329
        #1  unwind_entry (entry=entry@entry=0x7fffffff9180, arg=arg@entry=0x7ffff5642498) at util/machine.c:2329
        #2  0x00005555558370af in entry (arg=0x7ffff5642498, cb=0x5555557bdb50 <unwind_entry>, thread=<optimized out>, ip=18446744073709551615) at util/unwind-libunwind-local.c:586
        #3  get_entries (ui=ui@entry=0x7fffffff9620, cb=0x5555557bdb50 <unwind_entry>, arg=0x7ffff5642498, max_stack=<optimized out>) at util/unwind-libunwind-local.c:703
        #4  0x0000555555837192 in _unwind__get_entries (cb=<optimized out>, arg=<optimized out>, thread=<optimized out>, data=<optimized out>, max_stack=<optimized out>) at util/unwind-libunwind-local.c:725
        #5  0x00005555557c310f in thread__resolve_callchain_unwind (max_stack=127, sample=0x7fffffff9830, evsel=0x555555c7b3b0, cursor=0x7ffff5642498, thread=0x555555c7f6f0) at util/machine.c:2351
        #6  thread__resolve_callchain (thread=0x555555c7f6f0, cursor=0x7ffff5642498, evsel=0x555555c7b3b0, sample=0x7fffffff9830, parent=0x7fffffff97b8, root_al=0x7fffffff9750, max_stack=127) at util/machine.c:2378
        #7  0x00005555557ba4ee in sample__resolve_callchain (sample=<optimized out>, cursor=<optimized out>, parent=parent@entry=0x7fffffff97b8, evsel=<optimized out>, al=al@entry=0x7fffffff9750,
            max_stack=<optimized out>) at util/callchain.c:1085
      Signed-off-by: NMilian Wolff <milian.wolff@kdab.com>
      Tested-by: NSandipan Das <sandipan@linux.ibm.com>
      Acked-by: NJiri Olsa <jolsa@kernel.org>
      Cc: Jin Yao <yao.jin@linux.intel.com>
      Cc: Namhyung Kim <namhyung@kernel.org>
      Fixes: 2a9d5050 ("perf script: Show correct offsets for DWARF-based unwinding")
      Link: http://lkml.kernel.org/r/20180926135207.30263-1-milian.wolff@kdab.comSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      ff4ce288
  4. 12 9月, 2018 1 次提交
  5. 31 8月, 2018 5 次提交
  6. 20 8月, 2018 16 次提交
  7. 15 8月, 2018 2 次提交
  8. 14 8月, 2018 11 次提交
  9. 11 8月, 2018 1 次提交