1. 18 9月, 2014 2 次提交
  2. 14 8月, 2014 2 次提交
  3. 13 8月, 2014 2 次提交
  4. 31 7月, 2014 1 次提交
  5. 17 7月, 2014 3 次提交
  6. 08 7月, 2014 1 次提交
  7. 01 6月, 2014 1 次提交
  8. 16 4月, 2014 2 次提交
  9. 25 2月, 2014 1 次提交
  10. 24 2月, 2014 1 次提交
  11. 18 2月, 2014 1 次提交
  12. 01 2月, 2014 2 次提交
  13. 28 12月, 2013 2 次提交
  14. 18 12月, 2013 1 次提交
    • A
      perf symbols: Use consistent name for the DSO binary type member · 5f70619d
      Arnaldo Carvalho de Melo 提交于
      It was called "data_type", but in this context "data" is way too vague,
      it could mean the "data" ELF segment, or something else.
      
      Since we have dso__read_binary_type_filename() and the values this field
      receives are all DSO__BINARY_TYPE_<FOO> we may as well call it
      "binary_type" for consistency sake.
      
      It also seems more appropriate since it determines if we can do
      operations like annotation and DWARF unwinding, that needs more than
      just the symtab, requiring access to ELF text segments, CFI ELF
      sections, etc.
      
      Cc: Adrian Hunter <adrian.hunter@intel.com>
      Cc: David Ahern <dsahern@gmail.com>
      Cc: Frederic Weisbecker <fweisbec@gmail.com>
      Cc: Jiri Olsa <jolsa@redhat.com>
      Cc: Mike Galbraith <efault@gmx.de>
      Cc: Namhyung Kim <namhyung@kernel.org>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Stephane Eranian <eranian@google.com>
      Link: http://lkml.kernel.org/n/tip-2lkbqrn23uc2uvnn9w9in379@git.kernel.orgSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      5f70619d
  15. 17 12月, 2013 1 次提交
  16. 13 12月, 2013 1 次提交
  17. 11 12月, 2013 4 次提交
  18. 05 12月, 2013 1 次提交
  19. 28 11月, 2013 3 次提交
  20. 14 10月, 2013 4 次提交
  21. 11 10月, 2013 1 次提交
  22. 09 10月, 2013 2 次提交
  23. 03 9月, 2013 1 次提交
    • D
      perf tools: Fix symbol offset computation for some dsos · 0b8c25d9
      David Ahern 提交于
      For some dsos (e.g., libc, libpthread, kernel modules) the symbol offset
      is huge. e.g.,
      
      qemu-kvm 17238/17242 [007] 762235.640311:
          ffffffff816288a1 __schedule+0x451 ([kernel.kallsyms])
          ffffffff81629609 schedule+0x29 ([kernel.kallsyms])
          ffffffffa00a6ded kvm_vcpu_block+0xffffffffa00a106d (/lib/modules/3.11.0-rc1+/kernel/arch/x86/kvm/kvm.ko)
          ffffffffa00bae6b kvm_arch_vcpu_ioctl_run+0xffffffffa00a118b (/lib/modules/3.11.0-rc1+/kernel/arch/x86/kvm/kvm.ko)
          ffffffffa00a4d7a kvm_vcpu_ioctl+0xffffffffa00a141a (/lib/modules/3.11.0-rc1+/kernel/arch/x86/kvm/kvm.ko)
          ffffffff811a7bdb do_vfs_ioctl+0x8b ([kernel.kallsyms])
          ffffffff811a80c1 sys_ioctl+0x91 ([kernel.kallsyms])
          ffffffff81633182 system_call+0x72 ([kernel.kallsyms])
              7f882a97af27 __GI___ioctl+0x7f882a891007 (/lib64/libc-2.14.90.so)
                 100000002 [unknown] ([unknown])
      
      It seems to be maps with a non-0 start. Taking that into account the
      offsets are correct:
      
      qemu-kvm 17238/17242 [007] 762235.640311:
          ffffffff816288a1 __schedule+0x451 ([kernel.kallsyms])
          ffffffff81629609 schedule+0x29 ([kernel.kallsyms])
          ffffffffa00a6ded kvm_vcpu_block+0x6d (/lib/modules/3.11.0-rc1+/kernel/arch/x86/kvm/kvm.ko)
          ffffffffa00bae6b kvm_arch_vcpu_ioctl_run+0x18b (/lib/modules/3.11.0-rc1+/kernel/arch/x86/kvm/kvm.ko)
          ffffffffa00a4d7a kvm_vcpu_ioctl+0x41a (/lib/modules/3.11.0-rc1+/kernel/arch/x86/kvm/kvm.ko)
          ffffffff811a7bdb do_vfs_ioctl+0x8b ([kernel.kallsyms])
          ffffffff811a80c1 sys_ioctl+0x91 ([kernel.kallsyms])
          ffffffff81633182 system_call+0x72 ([kernel.kallsyms])
              7f882a97af27 __GI___ioctl+0x7 (/lib64/libc-2.14.90.so)
                 100000002 [unknown] ([unknown])
      Signed-off-by: NDavid Ahern <dsahern@gmail.com>
      Link: http://lkml.kernel.org/r/1375026512-45826-1-git-send-email-dsahern@gmail.comSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      0b8c25d9