1. 11 9月, 2012 1 次提交
    • J
      perf tools: Back [vdso] DSO with real data · 7dbf4dcf
      Jiri Olsa 提交于
      Storing data for VDSO shared object, because we need it for the post
      unwind processing.
      
      The VDSO shared object is same for all process on a running system, so
      it makes no difference when we store it inside the tracer - perf.
      
      When [vdso] map memory is hit, we retrieve [vdso] DSO image and store it
      into temporary file.
      
      During the build-id processing phase, the [vdso] DSO image is stored in
      build-id db, and build-id reference is made inside perf.data. The
      build-id vdso file object is called '[vdso]'. We don't use temporary
      file name which gets removed when record is finished.
      
      During report phase the vdso build-id object is treated as any other
      build-id DSO object.
      
      Adding following API for vdso object:
      
        bool is_vdso_map(const char *filename)
          - returns true if the filename matches vdso map name
      
        struct dso *vdso__dso_findnew(struct list_head *head)
          - find/create proper vdso DSO object
      
        vdso__exit(void)
          - removes temporary VDSO image if there's any
      
      This change makes backtrace dwarf post unwind possible from [vdso] maps.
      
      Following output is current report of [vdso] sample dwarf backtrace:
      
        # Overhead  Command      Shared Object                         Symbol
        # ........  .......  .................  .............................
        #
            99.52%       ex  [vdso]             [.] 0x00007fff3ace89af
                         |
                         --- 0x7fff3ace89af
      
      Following output is new report of [vdso] sample dwarf backtrace:
      
        # Overhead  Command      Shared Object                         Symbol
        # ........  .......  .................  .............................
        #
            99.52%       ex  [vdso]             [.] 0x00000000000009af
                         |
                         --- 0x7fff3ace89af
                             main
                             __libc_start_main
                             _start
      Signed-off-by: NJiri Olsa <jolsa@redhat.com>
      Acked-by: NPeter Zijlstra <a.p.zijlstra@chello.nl>
      Cc: Frederic Weisbecker <fweisbec@gmail.com>
      Cc: Ingo Molnar <mingo@elte.hu>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
      Link: http://lkml.kernel.org/r/1347295819-23177-5-git-send-email-jolsa@redhat.com
      [ committer note: s/ALIGN/PERF_ALIGN/g to cope with the android build changes ]
      Signed-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      7dbf4dcf
  2. 13 8月, 2012 1 次提交
  3. 10 8月, 2012 2 次提交
  4. 25 7月, 2012 3 次提交
    • D
      perf kvm: Limit repetitive guestmount message to once per directory · c80c3c26
      David Ahern 提交于
      After 7ed97ad4 use of the guestmount option without a subdir for *each*
      VM generates an error message for each sample related to that VM. Once
      per VM is enough.
      Signed-off-by: NDavid Ahern <dsahern@gmail.com>
      Cc: Frederic Weisbecker <fweisbec@gmail.com>
      Cc: Ingo Molnar <mingo@kernel.org>
      Cc: Jiri Olsa <jolsa@redhat.com>
      Cc: Namhyung Kim <namhyung@kernel.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Link: http://lkml.kernel.org/r/1342826756-64663-7-git-send-email-dsahern@gmail.comSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      c80c3c26
    • D
      perf kvm: Fix bug resolving guest kernel syms · adb5d2a4
      David Ahern 提交于
      Guest kernel symbols are not resolved despite passing the information
      needed to resolve them. e.g.,
      
      perf kvm --guest --guestmount=/tmp/guest-mount record -a -- sleep 1
      perf kvm --guest --guestmount=/tmp/guest-mount report --stdio
      
          36.55%  [guest/11399]  [unknown]         [g] 0xffffffff81600bc8
          33.19%  [guest/10474]  [unknown]         [g] 0x00000000c0116e00
          30.26%  [guest/11094]  [unknown]         [g] 0xffffffff8100a288
          43.69%  [guest/10474]  [unknown]         [g] 0x00000000c0103d90
          37.38%  [guest/11399]  [unknown]         [g] 0xffffffff81600bc8
          12.24%  [guest/11094]  [unknown]         [g] 0xffffffff810aa91d
           6.69%  [guest/11094]  [unknown]         [u] 0x00007fa784d721c3
      
      which is just pathetic.
      
      After a maddening 2 days sifting through perf minutia I found it --
      id_hdr_size is not initialized for guest machines. This shows up on the
      report side as random garbage for the cpu and timestamp, e.g.,
      
      29816 7310572949125804849 0x1ac0 [0x50]: PERF_RECORD_MMAP ...
      
      That messes up the sample sorting such that synthesized guest maps are
      processed last.
      
      With this patch you get a much more helpful report:
      
        12.11%  [guest/11399]  [guest.kernel.kallsyms.11399]  [g] irqtime_account_process_tick
        10.58%  [guest/11399]  [guest.kernel.kallsyms.11399]  [g] run_timer_softirq
         6.95%  [guest/11094]  [guest.kernel.kallsyms.11094]  [g] printk_needs_cpu
         6.50%  [guest/11094]  [guest.kernel.kallsyms.11094]  [g] do_timer
         6.45%  [guest/11399]  [guest.kernel.kallsyms.11399]  [g] idle_balance
         4.90%  [guest/11094]  [guest.kernel.kallsyms.11094]  [g] native_read_tsc
          ...
      
      v2:
      - changed rbtree walk to use rb_first per Namhyung's suggestion
      Tested-by: NJiri Olsa <jolsa@redhat.com>
      Signed-off-by: NDavid Ahern <dsahern@gmail.com>
      Cc: Frederic Weisbecker <fweisbec@gmail.com>
      Cc: Ingo Molnar <mingo@kernel.org>
      Cc: Jiri Olsa <jolsa@redhat.com>
      Cc: Namhyung Kim <namhyung@kernel.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Link: http://lkml.kernel.org/r/1342826756-64663-5-git-send-email-dsahern@gmail.comSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      adb5d2a4
    • D
      perf kvm: Set name for VM process in guest machine · 5cd95c2d
      David Ahern 提交于
      COMM events are not generated in the context of a guest machine, so the
      thread name is never set for the VMM process. For example, the qemu-kvm
      name applies to the process in the host machine, not the guest machine.
      So, samples for guest machines are currently displayed as:
      
          99.67%     :5671  [unknown]         [g] 0xffffffff81366b41
      
      where 5671 is the pid of the VMM. With this patch the samples in the guest
      machine are shown as:
      
          18.43%  [guest/5671]  [unknown]           [g] 0xffffffff810d68b7
      Tested-by: NJiri Olsa <jolsa@redhat.com>
      Signed-off-by: NDavid Ahern <dsahern@gmail.com>
      Cc: Frederic Weisbecker <fweisbec@gmail.com>
      Cc: Ingo Molnar <mingo@kernel.org>
      Cc: Jiri Olsa <jolsa@redhat.com>
      Cc: Namhyung Kim <namhyung@kernel.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Link: http://lkml.kernel.org/r/1342826756-64663-3-git-send-email-dsahern@gmail.comSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      5cd95c2d
  5. 03 7月, 2012 1 次提交
    • D
      perf kvm: Fix segfault with report and mixed guestmount use · 7ed97ad4
      David Ahern 提交于
      Using the guestmount option on record:
          $ perf kvm --guest --host --guestmount=/tmp/guest-mount record -ag
      
      But not the subsequent report:
          $ perf kvm report
      
      causes a SEGFAULT in the usual place:
      (gdb) bt
      0  0x0000000000470356 in machine__mmap_name (self=0x0, bf=0x7fffffffbdb0 " z\370\367\377\177", size=
          4096) at util/map.c:712
      1  0x00000000004453e8 in perf_event__process_kernel_mmap (tool=0x7fffffffde10, event=0x7ffff7f87e38,
          machine=0x0) at util/event.c:550
      2  0x00000000004458c9 in perf_event__process_mmap (tool=0x7fffffffde10, event=0x7ffff7f87e38, sample=
          0x7fffffffd2a0, machine=0x0) at util/event.c:656
      3  0x00000000004733e0 in perf_session_deliver_event (session=0x91aca0, event=0x7ffff7f87e38, sample=
          0x7fffffffd2a0, tool=0x7fffffffde10, file_offset=7736) at util/session.c:979
      ...
      
      The MMAP events in this case already contain the full path to the
      module. No need to require it for the report path to.
      Signed-off-by: NDavid Ahern <dsahern@gmail.com>
      Cc: Frederic Weisbecker <fweisbec@gmail.com>
      Cc: Ingo Molnar <mingo@kernel.org>
      Cc: Jiri Olsa <jolsa@redhat.com>
      Cc: Namhyung Kim <namhyung@gmail.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Link: http://lkml.kernel.org/r/1341241977-71535-1-git-send-email-dsahern@gmail.comSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      7ed97ad4
  6. 06 4月, 2012 1 次提交
  7. 31 1月, 2012 2 次提交
  8. 28 11月, 2011 1 次提交
  9. 19 10月, 2011 1 次提交
  10. 30 9月, 2011 2 次提交
  11. 23 1月, 2011 1 次提交
    • A
      perf tools: Fix 64 bit integer format strings · 9486aa38
      Arnaldo Carvalho de Melo 提交于
      Using %L[uxd] has issues in some architectures, like on ppc64.  Fix it
      by making our 64 bit integers typedefs of stdint.h types and using
      PRI[ux]64 like, for instance, git does.
      
      Reported by Denis Kirjanov that provided a patch for one case, I went
      and changed all cases.
      Reported-by: NDenis Kirjanov <dkirjanov@kernel.org>
      Tested-by: NDenis Kirjanov <dkirjanov@kernel.org>
      LKML-Reference: <20110120093246.GA8031@hera.kernel.org>
      Cc: Denis Kirjanov <dkirjanov@kernel.org>
      Cc: Frederic Weisbecker <fweisbec@gmail.com>
      Cc: Ingo Molnar <mingo@elte.hu>
      Cc: Mike Galbraith <efault@gmx.de>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Pingtian Han <phan@redhat.com>
      Cc: Stephane Eranian <eranian@google.com>
      Cc: Tom Zanussi <tzanussi@gmail.com>
      Signed-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      9486aa38
  12. 03 8月, 2010 2 次提交
    • A
      perf tools: Don't keep unreferenced maps when unmaps are detected · 0a1eae39
      Arnaldo Carvalho de Melo 提交于
      For a file with:
      
      [root@emilia linux-2.6-tip]# perf report -D -fi allmodconfig-j32.perf.data | grep events:
           TOTAL events:      36933
            MMAP events:       9056
            LOST events:          0
            COMM events:       1702
            EXIT events:       1887
        THROTTLE events:          8
      UNTHROTTLE events:          8
            FORK events:       1894
            READ events:          0
          SAMPLE events:      22378
            ATTR events:          0
      EVENT_TYPE events:          0
      TRACING_DATA events:          0
        BUILD_ID events:          0
      [root@emilia linux-2.6-tip]#
      
      Testing with valgrind and making perf_session__delete() a nop, so that
      we can notice how many maps were actually deleted due to not having any
      samples on it:
      
      ==== HEAP SUMMARY:
      
      Before:
      
      ==10339==     in use at exit: 8,909,997 bytes in 68,690 blocks
      ==10339==   total heap usage: 78,696 allocs, 10,007 frees, 11,925,853 bytes allocated
      
      After:
      
      ==10506==     in use at exit: 8,902,605 bytes in 68,606 blocks
      ==10506==   total heap usage: 78,696 allocs, 10,091 frees, 11,925,853 bytes allocated
      
      I.e. just 84 detected unmaps with no hits out of 9056 for this workload,
      not much, but in some other long running workload this may save more
      bytes.
      
      Cc: Frederic Weisbecker <fweisbec@gmail.com>
      Cc: Mike Galbraith <efault@gmx.de>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Stephane Eranian <eranian@google.com>
      LKML-Reference: <new-submission>
      Signed-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      0a1eae39
    • A
      perf session: Free the ref_reloc_sym memory at the right place · 076c6e45
      Arnaldo Carvalho de Melo 提交于
      Which is at perf_session__destroy_kernel_maps, counterpart to the
      perf_session__create_kernel_maps where the kmap structure is located, just
      after the vmlinux_maps.
      
      Make it also check if the kernel maps were actually created, which may not
      be the case if, for instance, perf_session__new can't complete due to
      permission problems in, for instance, a 'perf report' case, when a
      segfault will take place, that is how this was noticed.
      
      The problem was introduced in d65a458b, thus post .35.
      
      This also adds code to release guest machines as them are also created
      in perf_session__create_kernel_maps, so should be deleted on this newly
      introduced counterpart, perf_session__destroy_kernel_maps.
      
      Cc: Frederic Weisbecker <fweisbec@gmail.com>
      Cc: Mike Galbraith <efault@gmx.de>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Stephane Eranian <eranian@google.com>
      LKML-Reference: <new-submission>
      Signed-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      076c6e45
  13. 31 7月, 2010 2 次提交
    • A
      perf tools: Release session and symbol resources on exit · d65a458b
      Arnaldo Carvalho de Melo 提交于
      So that we reduce the noise when looking for leaks using tools such as
      valgrind.
      
      Cc: Frederic Weisbecker <fweisbec@gmail.com>
      Cc: Mike Galbraith <efault@gmx.de>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Stephane Eranian <eranian@google.com>
      LKML-Reference: <new-submission>
      Signed-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      d65a458b
    • A
      perf tools: Release thread resources on PERF_RECORD_EXIT · 591765fd
      Arnaldo Carvalho de Melo 提交于
      For long running sessions with many threads with short lifetimes the
      amount of memory that the buildid process takes is too much.
      
      Since we don't have hist_entries that may be pointing to them, we can
      just release the resources associated with each thread when the exit
      (PERF_RECORD_EXIT) event is received.
      
      For normal processing we need to annotate maps with hits, and thus
      hist_entries pointing to it and drop the ones that had none. Will be
      done in a followup patch.
      
      Cc: David S. Miller <davem@davemloft.net>
      Cc: Frederic Weisbecker <fweisbec@gmail.com>
      Cc: Ingo Molnar <mingo@elte.hu>
      Cc: Mike Galbraith <efault@gmx.de>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Stephane Eranian <eranian@google.com>
      Cc: Tom Zanussi <tzanussi@gmail.com>
      LKML-Reference: <new-submission>
      Signed-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      591765fd
  14. 27 7月, 2010 1 次提交
  15. 10 5月, 2010 1 次提交
    • A
      perf session: Embed the host machine data on perf_session · 1f626bc3
      Arnaldo Carvalho de Melo 提交于
      We have just one host on a given session, and that is the most common
      setup right now, so embed a ->host_machine struct machine instance
      directly in the perf_session class, check if we're looking for it before
      going to the rb_tree.
      
      This also fixes a problem found when we try to process old perf.data
      files where we didn't have MMAP events for the kernel and modules and
      thus don't create the kernel maps, do it in event__preprocess_sample if
      it wasn't already.
      Reported-by: NIngo Molnar <mingo@elte.hu>
      Cc: Frédéric Weisbecker <fweisbec@gmail.com>
      Cc: Mike Galbraith <efault@gmx.de>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
      Cc: Tom Zanussi <tzanussi@gmail.com>
      Cc: Zhang, Yanmin <yanmin_zhang@linux.intel.com>
      LKML-Reference: <new-submission>
      Signed-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      1f626bc3
  16. 28 4月, 2010 3 次提交
    • A
      perf machine: Adopt some map_groups functions · d28c6223
      Arnaldo Carvalho de Melo 提交于
      Those functions operated on members now grouped in 'struct machine', so
      move those methods to this new class.
      
      The changes made to 'perf probe' shows that using this abstraction
      inserting probes on guests almost got supported for free.
      
      Cc: Avi Kivity <avi@redhat.com>
      Cc: Frédéric Weisbecker <fweisbec@gmail.com>
      Cc: Masami Hiramatsu <mhiramat@redhat.com>
      Cc: Mike Galbraith <efault@gmx.de>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
      Cc: Zhang, Yanmin <yanmin_zhang@linux.intel.com>
      LKML-Reference: <new-submission>
      Signed-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      d28c6223
    • A
      perf machine: Pass buffer size to machine__mmap_name · 48ea8f54
      Arnaldo Carvalho de Melo 提交于
      Don't blindly assume that the size of the buffer is enough, use
      snprintf.
      
      Cc: Avi Kivity <avi@redhat.com>
      Cc: Frédéric Weisbecker <fweisbec@gmail.com>
      Cc: Mike Galbraith <efault@gmx.de>
      Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Zhang, Yanmin <yanmin_zhang@linux.intel.com>
      LKML-Reference: <new-submission>
      Signed-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      48ea8f54
    • A
      perf tools: Rename "kernel_info" to "machine" · 23346f21
      Arnaldo Carvalho de Melo 提交于
      struct kernel_info and kerninfo__ are too vague, what they really
      describe are machines, virtual ones or hosts.
      
      There are more changes to introduce helpers to shorten function calls
      and to make more clear what is really being done, but I left that for
      subsequent patches.
      
      Cc: Avi Kivity <avi@redhat.com>
      Cc: Frédéric Weisbecker <fweisbec@gmail.com>
      Cc: Mike Galbraith <efault@gmx.de>
      Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Zhang, Yanmin <yanmin_zhang@linux.intel.com>
      LKML-Reference: <new-submission>
      Signed-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      23346f21
  17. 19 4月, 2010 1 次提交
  18. 03 4月, 2010 2 次提交
  19. 26 3月, 2010 2 次提交
  20. 25 2月, 2010 1 次提交
    • A
      perf symbols: Improve debugging information about symtab origins · 3846df2e
      Arnaldo Carvalho de Melo 提交于
      Be more clear about DSO long names and tell from which file
      kernel symbols were obtained, all in --verbose mode:
      
          [root@mica ~]# perf report -v > /dev/null
          Looking at the vmlinux_path (5 entries long)
          Using /lib/modules/2.6.33-rc8-tip-00777-g0918527-dirty/build/vmlinux for symbols
          [root@mica ~]# mv /lib/modules/2.6.33-rc8-tip-00777-g0918527-dirty/build/vmlinux /tmp/dd
          [root@mica ~]# perf report -v > /dev/null
          Looking at the vmlinux_path (5 entries long)
          Using /proc/kallsyms for symbols
          [root@mica ~]#
      Signed-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      Cc: Frédéric Weisbecker <fweisbec@gmail.com>
      Cc: Mike Galbraith <efault@gmx.de>
      Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
      Cc: Paul Mackerras <paulus@samba.org>
      LKML-Reference: <1266866139-6361-1-git-send-email-acme@infradead.org>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      3846df2e
  21. 08 2月, 2010 1 次提交
    • K
      perf top: Fix annotate for userspace · ee11b90b
      Kirill Smelkov 提交于
      First, for programs and prelinked libraries, annotate code was
      fooled by objdump output IPs (src->eip in the code) being
      wrongly converted to absolute IPs. In such case there were no
      conversion needed, but in
      
         src->eip = strtoull(src->line, NULL, 16);
         src->eip = map->unmap_ip(map, src->eip); // = eip + map->start - map->pgoff
      
      we were reading absolute address from objdump (e.g. 8048604) and
      then almost doubling it, because eip & map->start are
      approximately close for small programs.
      
      Needless to say, that later, in record_precise_ip() there was no
      matching with real runtime IPs.
      
      And second, like with `perf annotate` the problem with
      non-prelinked *.so was that we were doing rip -> objdump address
      conversion wrong.
      
      Also, because unlike `perf annotate`, `perf top` code does
      annotation based on absolute IPs for performance reasons(*), new
      helper for mapping objdump addresse to IP is introduced.
      
      (*) we get samples info in absolute IPs, and since we do lots of
          hit-testing on absolute IPs at runtime in record_precise_ip(), it's
          better to convert objdump addresses to IPs once and do no conversion
          at runtime.
      
      I also had to fix how objdump output is parsed (with hardcoded
      8/16 characters format, which was inappropriate for ET_DYN dsos
      with small addresses like '4ac')
      
      Also note, that not all objdump output lines has associtated
      IPs, e.g. look at source lines here:
      
          000004ac <my_strlen>:
          extern "C"
          int my_strlen(const char *s)
           4ac:   55                      push   %ebp
           4ad:   89 e5                   mov    %esp,%ebp
           4af:   83 ec 10                sub    $0x10,%esp
          {
              int len = 0;
           4b2:   c7 45 fc 00 00 00 00    movl   $0x0,-0x4(%ebp)
           4b9:   eb 08                   jmp    4c3 <my_strlen+0x17>
      
              while (*s) {
                  ++len;
           4bb:   83 45 fc 01             addl   $0x1,-0x4(%ebp)
                  ++s;
           4bf:   83 45 08 01             addl   $0x1,0x8(%ebp)
      
      So we mark them with eip=0, and ignore such lines in annotate
      lookup code.
      Signed-off-by: NKirill Smelkov <kirr@landau.phys.spbu.ru>
      [ Note: one hunk of this patch was applied by Mike in 57d81889 ]
      Signed-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      Cc: Mike Galbraith <efault@gmx.de>
      LKML-Reference: <1265550376-12665-1-git-send-email-acme@infradead.org>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      ee11b90b
  22. 04 2月, 2010 3 次提交
    • K
      perf annotate: Fix it for non-prelinked *.so · 7a2b6209
      Kirill Smelkov 提交于
      The problem was we were incorrectly calculating objdump
      addresses for sym->start and sym->end, look:
      
      For simple ET_DYN type DSO (*.so) with one function, objdump -dS
      output is something like this:
      
          000004ac <my_strlen>:
          int my_strlen(const char *s)
           4ac:   55                      push   %ebp
           4ad:   89 e5                   mov    %esp,%ebp
           4af:   83 ec 10                sub    $0x10,%esp
          {
      
      i.e. we have relative-to-dso-mapping IPs (=RIP) there.
      
      For ET_EXEC type and probably for prelinked libs as well (sorry
      can't test - I don't use prelink) objdump outputs absolute IPs,
      e.g.
      
          08048604 <zz_strlen>:
          extern "C"
          int zz_strlen(const char *s)
           8048604:       55                      push   %ebp
           8048605:       89 e5                   mov    %esp,%ebp
           8048607:       83 ec 10                sub    $0x10,%esp
          {
      
      So, if sym->start is always relative to dso mapping(*), we'll
      have to unmap it for ET_EXEC like cases, and leave as is for
      ET_DYN cases.
      
      (*) and it is - we've explicitely made it relative. Look for
          adjust_symbols handling in dso__load_sym()
      
      Previously we were always unmapping sym->start and for ET_DYN
      dsos resulting addresses were wrong, and so objdump output was
      empty.
      
      The end result was that perf annotate output for symbols from
      non-prelinked *.so had always 0.00% percents only, which is
      wrong.
      
      To fix it, let's introduce a helper for converting rip to
      objdump address, and also let's document what map_ip() and
      unmap_ip() do -- I had to study sources for several hours to
      understand it.
      Signed-off-by: NKirill Smelkov <kirr@landau.phys.spbu.ru>
      Signed-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      Cc: Mike Galbraith <efault@gmx.de>
      LKML-Reference: <1265223128-11786-8-git-send-email-acme@infradead.org>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      7a2b6209
    • A
      perf symbols: Ditch vdso global variable · 8d92c02a
      Arnaldo Carvalho de Melo 提交于
      We can check using strcmp, most DSOs don't start with '[' so the
      test is cheap enough and we had to test it there anyway since
      when reading perf.data files we weren't calling the routine that
      created this global variable and thus weren't setting it as
      "loaded", which was causing a bogus:
      
        Failed to open [vdso], continuing without symbols
      
      Message as the first line of 'perf report'.
      Signed-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      Cc: Frédéric Weisbecker <fweisbec@gmail.com>
      Cc: Mike Galbraith <efault@gmx.de>
      Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
      Cc: Paul Mackerras <paulus@samba.org>
      LKML-Reference: <1265223128-11786-3-git-send-email-acme@infradead.org>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      8d92c02a
    • A
      perf symbols: Remove perf_session usage in symbols layer · 9de89fe7
      Arnaldo Carvalho de Melo 提交于
      I noticed while writing the first test in 'perf regtest' that to
      just test the symbol handling routines one needs to create a
      perf session, that is a layer centered on a perf.data file,
      events, etc, so I untied these layers.
      
      This reduces the complexity for the users as the number of
      parameters to most of the symbols and session APIs now was
      reduced while not adding more state to all the map instances by
      only having data that is needed to split the kernel (kallsyms
      and ELF symtab sections) maps and do vmlinux relocation on the
      main kernel map.
      Signed-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      Cc: Frédéric Weisbecker <fweisbec@gmail.com>
      Cc: Mike Galbraith <efault@gmx.de>
      Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
      Cc: Paul Mackerras <paulus@samba.org>
      LKML-Reference: <1265223128-11786-1-git-send-email-acme@infradead.org>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      9de89fe7
  23. 16 12月, 2009 1 次提交
    • M
      perf probe: Check build-id of vmlinux · a128168d
      Masami Hiramatsu 提交于
      Check build-id of vmlinux by using functions in symbol.c.
      This also exposes map__load() for getting vmlinux path,
      and removes vmlinux path list in builtin-probe.c,
      because symbol.c already has that. Checking build-id
      prevents users to open old or different debuginfo from
      current running kernel.
      Signed-off-by: NMasami Hiramatsu <mhiramat@redhat.com>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Arnaldo Carvalho de Melo <acme@redhat.com>
      Cc: Steven Rostedt <rostedt@goodmis.org>
      Cc: Jim Keniston <jkenisto@us.ibm.com>
      Cc: Ananth N Mavinakayanahalli <ananth@in.ibm.com>
      Cc: Christoph Hellwig <hch@infradead.org>
      Cc: Frank Ch. Eigler <fche@redhat.com>
      Cc: Jason Baron <jbaron@redhat.com>
      Cc: K.Prasad <prasad@linux.vnet.ibm.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Srikar Dronamraju <srikar@linux.vnet.ibm.com>
      Cc: systemtap <systemtap@sources.redhat.com>
      Cc: DLE <dle-develop@lists.sourceforge.net>
      Cc: Frederic Weisbecker <fweisbec@gmail.com>
      LKML-Reference: <20091215153232.17436.45539.stgit@dhcp-100-2-132.bos.redhat.com>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      a128168d
  24. 14 12月, 2009 1 次提交
    • A
      perf session: Move kmaps to perf_session · 4aa65636
      Arnaldo Carvalho de Melo 提交于
      There is still some more work to do to disentangle map creation
      from DSO loading, but this happens only for the kernel, and for
      the early adopters of perf diff, where this disentanglement
      matters most, we'll be testing different kernels, so no problem
      here.
      
      Further clarification: right now we create the kernel maps for
      the various modules and discontiguous kernel text maps when
      loading the DSO, we should do it as a two step process, first
      creating the maps, for multiple mappings with the same DSO
      store, then doing the dso load just once, for the first hit on
      one of the maps sharing this DSO backing store.
      Signed-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      Cc: Frédéric Weisbecker <fweisbec@gmail.com>
      Cc: Mike Galbraith <efault@gmx.de>
      Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
      Cc: Paul Mackerras <paulus@samba.org>
      LKML-Reference: <1260741029-4430-6-git-send-email-acme@infradead.org>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      4aa65636
  25. 12 12月, 2009 2 次提交
    • A
      perf symbols: Ditch dso->find_symbol · ea08d8cb
      Arnaldo Carvalho de Melo 提交于
      It is always wired to dso__find_symbol.
      Signed-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      Cc: Frédéric Weisbecker <fweisbec@gmail.com>
      Cc: Mike Galbraith <efault@gmx.de>
      Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
      Cc: Paul Mackerras <paulus@samba.org>
      LKML-Reference: <1260564999-13371-1-git-send-email-acme@infradead.org>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      ea08d8cb
    • A
      perf symbols: Allow lookups by symbol name too · 79406cd7
      Arnaldo Carvalho de Melo 提交于
      Configurable via symbol_conf.sort_by_name, so that the cost of an
      extra rb_node on all 'struct symbol' instances is not paid by tools
      that only want to decode addresses.
      
      How to use it:
      
      	symbol_conf.sort_by_name = true;
      	symbol_init(&symbol_conf);
      
      	struct map *map = map_groups__find_by_name(kmaps, MAP__VARIABLE, "[kernel.kallsyms]");
      
      	if (map == NULL) {
      		pr_err("couldn't find map!\n");
      		kernel_maps__fprintf(stdout);
      	} else {
      		struct symbol *sym = map__find_symbol_by_name(map, sym_filter, NULL);
      		if (sym == NULL)
      			pr_err("couldn't find symbol %s!\n", sym_filter);
      		else
      			pr_info("symbol %s: %#Lx-%#Lx \n", sym_filter, sym->start, sym->end);
      	}
      
      Looking over the vmlinux/kallsyms is common enough that I'll add a
      variable to the upcoming struct perf_session to avoid the need to
      use map_groups__find_by_name to get the main vmlinux/kallsyms map.
      
      The above example looks on the 'variable' symtab, but it is just
      like that for the functions one.
      
      Also the sort operation is done when we first use
      map__find_symbol_by_name, in a lazy way.
      Signed-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      Cc: Frédéric Weisbecker <fweisbec@gmail.com>
      Cc: Masami Hiramatsu <mhiramat@redhat.com>
      Cc: Mike Galbraith <efault@gmx.de>
      Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
      Cc: Paul Mackerras <paulus@samba.org>
      LKML-Reference: <1260564622-12392-1-git-send-email-acme@infradead.org>
      Signed-off-by: NIngo Molnar <mingo@elte.hu>
      79406cd7
  26. 28 11月, 2009 1 次提交