1. 23 6月, 2016 4 次提交
    • H
      perf unwind: Change macro names of perf register · 78ff1d6d
      He Kuang 提交于
      Use macro name prefixed with "LIBUNWIND_ARCH" for better understanding
      that the regs used by callbacks of libunwind are arch specific. The real
      regs used should be defined in the wrapper file of
      "unwind-libunwind-local.c" for each supported arch.
      Signed-off-by: NHe Kuang <hekuang@huawei.com>
      Acked-by: NJiri Olsa <jolsa@kernel.org>
      Cc: Adrian Hunter <adrian.hunter@intel.com>
      Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
      Cc: Andi Kleen <ak@linux.intel.com>
      Cc: David Ahern <dsahern@gmail.com>
      Cc: Ekaterina Tumanova <tumanova@linux.vnet.ibm.com>
      Cc: Josh Poimboeuf <jpoimboe@redhat.com>
      Cc: Kan Liang <kan.liang@intel.com>
      Cc: Masami Hiramatsu <mhiramat@kernel.org>
      Cc: Namhyung Kim <namhyung@kernel.org>
      Cc: Pekka Enberg <penberg@kernel.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Stephane Eranian <eranian@google.com>
      Cc: Sukadev Bhattiprolu <sukadev@linux.vnet.ibm.com>
      Cc: Wang Nan <wangnan0@huawei.com>
      Link: http://lkml.kernel.org/r/1466578626-92406-2-git-send-email-hekuang@huawei.comSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      78ff1d6d
    • H
      perf tools: Find right DSO taking into account if binary is 32 or 64-bit · 76c588f1
      He Kuang 提交于
      There's a problem in machine__findnew_vdso(), vdso buildid generated by a
      32-bit machine stores it with the name 'vdso', but when processing buildid on a
      64-bit machine with the same 'perf.data', perf will search for vdso named as
      'vdso32' and get failed.
      
      This patch tries to find the existing dsos in machine->dsos by thread dso_type.
      64-bit thread tries to find vdso with name 'vdso', because all 64-bit vdso is
      named as that. 32-bit thread first tries to find vdso with name 'vdso32' if
      this thread was run on 64-bit machine, if failed, then it tries 'vdso' which
      indicates that the thread was run on 32-bit machine when recording.
      
      Committer note:
      
      Additional explanation by Adrian Hunter:
      
      We match maps to builds ids using the file name - consider
      machine__findnew_[v]dso() called in map__new().  So in the context of a perf
      data file, we consider the file name to be unique.
      
      A vdso map does not have a file name - all we know is that it is vdso.  We look
      at the thread to tell if it is 32-bit, 64-bit or x32.  Then we need to get the
      build id which has been recorded using short name "[vdso]" or "[vdso32]" or
      "[vdsox32]".
      
      The problem is that on a 32-bit machine, we use the name "[vdso]".  If you take
      a 32-bit perf data file to a 64-bit machine, it gets hard to figure out if
      "[vdso]" is 32-bit or 64-bit.
      
      This patch solves that problem.
      
       ----
      
      This also merges a followup patch fixing a problem introduced by the
      original submission of this patch, that would crash 'perf record' when
      recording samples for a 32-bit app on a 64-bit system.
      Signed-off-by: NHe Kuang <hekuang@huawei.com>
      Acked-by: NAdrian Hunter <adrian.hunter@intel.com>
      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: David Ahern <dsahern@gmail.com>
      Cc: Ekaterina Tumanova <tumanova@linux.vnet.ibm.com>
      Cc: Jiri Olsa <jolsa@redhat.com>
      Cc: Josh Poimboeuf <jpoimboe@redhat.com>
      Cc: Kan Liang <kan.liang@intel.com>
      Cc: Masami Hiramatsu <mhiramat@kernel.org>
      Cc: Namhyung Kim <namhyung@kernel.org>
      Cc: Pekka Enberg <penberg@kernel.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Stephane Eranian <eranian@google.com>
      Cc: Sukadev Bhattiprolu <sukadev@linux.vnet.ibm.com>
      Cc: Wang Nan <wangnan0@huawei.com>
      Link: http://lkml.kernel.org/r/1463475894-163531-1-git-send-email-hekuang@huawei.com
      Link: http://lkml.kernel.org/r/1466578626-92406-6-git-send-email-hekuang@huawei.comSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      76c588f1
    • T
      perf config: Move config declarations from util/cache.h to util/config.h · 41840d21
      Taeung Song 提交于
      Lately util/config.h has been added but util/cache.h has declarations of
      functions and a global variable for config features.
      
      To manage codes about configuration at one spot, move them to
      util/config.h and let source files that need config features include
      config.h And if the source files that included previous cache.h need
      only config.h, remove including cache.h.
      Signed-off-by: NTaeung Song <treeze.taeung@gmail.com>
      Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
      Cc: Jiri Olsa <jolsa@redhat.com>
      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/r/1466672119-4852-2-git-send-email-treeze.taeung@gmail.comSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      41840d21
    • H
      perf tools: Let python use correct gcc for build_ext · 48d8d5db
      He Kuang 提交于
      Currently, python uses host gcc instead of cross-compile gcc in the last
      step of compiling build_ext(remove '--quiet' to show verbose):
      
        cross-gcc ...
        cross-gcc ...
        creating ~/out/python_ext_build/lib
        gcc -pthread -shared -Wl,-z ...
      
      This is wrong but may not cause any errors unless the features detected
      by cross-compiler do not match those for host compiler, and causes the
      following errors:
      
        /usr/lib64/gcc/bin/ld: cannot find -lunwind-x86
        collect2: error: ld returned 1 exit status
        error: command 'gcc' failed with exit status 1
        cp: cannot stat ‘~/out/python_ext_build/lib/perf.so’: No such file or directory
        Makefile.perf:257: recipe for target '~/out/python/perf.so' failed
        make[1]: *** [~/out/python/perf.so] Error 1
        Makefile:68: recipe for target 'all' failed
        make: *** [all] Error 2
      
      This issue is also reported and anwsered on stackoverflow.
      Link: http://stackoverflow.com/questions/5986256/python-distutils-gcc-pathSigned-off-by: NHe Kuang <hekuang@huawei.com>
      Cc: Adrian Hunter <adrian.hunter@intel.com>
      Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
      Cc: Andi Kleen <ak@linux.intel.com>
      Cc: David Ahern <dsahern@gmail.com>
      Cc: Ekaterina Tumanova <tumanova@linux.vnet.ibm.com>
      Cc: Jiri Olsa <jolsa@redhat.com>
      Cc: Josh Poimboeuf <jpoimboe@redhat.com>
      Cc: Kan Liang <kan.liang@intel.com>
      Cc: Masami Hiramatsu <mhiramat@kernel.org>
      Cc: Namhyung Kim <namhyung@kernel.org>
      Cc: Pekka Enberg <penberg@kernel.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Stephane Eranian <eranian@google.com>
      Cc: Sukadev Bhattiprolu <sukadev@linux.vnet.ibm.com>
      Cc: Wang Nan <wangnan0@huawei.com>
      Link: http://lkml.kernel.org/r/1466578626-92406-5-git-send-email-hekuang@huawei.comSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      48d8d5db
  2. 22 6月, 2016 22 次提交
  3. 16 6月, 2016 3 次提交
  4. 15 6月, 2016 11 次提交