1. 24 9月, 2011 6 次提交
  2. 18 8月, 2011 5 次提交
  3. 12 8月, 2011 11 次提交
    • F
      ARM: fix perf build with uclibc toolchains · 0ac8e58f
      Florian Fainelli 提交于
      libio.h is not provided by uClibc, in order to be able to test the
      definition of __UCLIBC__ we need to include stdlib.h, which also
      includes stddef.h, providing the definition of 'NULL'.
      Signed-off-by: NFlorian Fainelli <florian@openwrt.org>
      Signed-off-by: NWill Deacon <will.deacon@arm.com>
      0ac8e58f
    • M
      perf probe: Filter out redundant inline-instances · 3f4460a2
      Masami Hiramatsu 提交于
      With gcc4.6, some instances of concrete inlined function looks redundant
      and broken, because it appears inside of a concrete instance and its
      call_file and call_line are same as the original abstruct's decl_file
      and decl_line respectively.
      
      e.g.
       [  d1aa]    subprogram
                   external             (flag) Yes
                   name                 (strp) "add_timer"
                   decl_file            (data1) 2		;here is original
                   decl_line            (data2) 847		;line and file
                   prototyped           (flag) Yes
                   inline               (data1) inlined (1)
                   sibling              (ref4) [  d1c6]
      ...
       [ 11d84]    subprogram
                   abstract_origin      (ref4) [  d1aa]	; concrete instance
                   low_pc               (addr) .text+0x000000000000246f <add_timer>
                   high_pc              (addr) .text+0x000000000000248b <mod_timer_pending>
                   frame_base           (block1)               [   0] call_frame_cfa
                   sibling              (ref4) [ 11dd9]
       [ 11d9f]      formal_parameter
                     abstract_origin      (ref4) [  d1b9]
                     location             (data4) location list [  701b]
       [ 11da8]      inlined_subroutine
                     abstract_origin      (ref4) [  d1aa]	; redundant instance
                     low_pc               (addr) .text+0x000000000000247e <add_timer+0xf>
                     high_pc              (addr) .text+0x0000000000002480 <add_timer+0x11>
                     call_file            (data1) 2		; call line and file
                     call_line            (data2) 847		; are same as above
      
      Those redundant instances leads unwilling results;
      
      e.g. find probe points inside of functions even if we specify
      a function entry as below;
      
      $ perf probe -V add_timer
      Available variables at add_timer
              @<add_timer+0>
                      struct timer_list*      timer
              @<add_timer+15>
                      (No matched variables)
      
      So, this filters out those redundant instances based on call-site and
      decl-site information.
      
      Cc: Frederic Weisbecker <fweisbec@gmail.com>
      Cc: Ingo Molnar <mingo@elte.hu>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Pekka Enberg <penberg@kernel.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: yrl.pp-manager.tt@hitachi.com
      Link: http://lkml.kernel.org/r/20110811110317.19900.59525.stgit@fedora15Signed-off-by: NMasami Hiramatsu <masami.hiramatsu.pt@hitachi.com>
      Signed-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      3f4460a2
    • M
      perf probe: Search concrete out-of-line instances · db0d2c64
      Masami Hiramatsu 提交于
      gcc 4.6 generates a concrete out-of-line instance when there is a
      function which is implicitly inlined somewhere but also has its own
      instance. The concrete out-of-line instance means that it has an
      abstract origin of the function which is referred by not only
      inlined-subroutines but also a concrete subprogram.
      
      Since current dwarf_func_inline_instances() can find only instances of
      inlined-subroutines, this introduces new die_walk_instances() to find
      both of subprogram and inlined-subroutines.
      
      e.g. without this,
      Available variables at sched_group_rt_period
              @<cpu_rt_period_read_uint+9>
                      struct task_group*      tg
      
      perf probe failed to find actual subprogram instance of
      sched_group_rt_period().
      
      With this,
      
      Available variables at sched_group_rt_period
              @<cpu_rt_period_read_uint+9>
                      struct task_group*      tg
              @<sched_group_rt_period+0>
                      struct task_group*      tg
      
      Now it found the sched_group_rt_period() itself.
      
      Cc: Frederic Weisbecker <fweisbec@gmail.com>
      Cc: Ingo Molnar <mingo@elte.hu>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Pekka Enberg <penberg@kernel.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: yrl.pp-manager.tt@hitachi.com
      Link: http://lkml.kernel.org/r/20110811110311.19900.63997.stgit@fedora15Signed-off-by: NMasami Hiramatsu <masami.hiramatsu.pt@hitachi.com>
      Signed-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      db0d2c64
    • M
      perf probe: Avoid searching variables in intermediate scopes · f182e3e1
      Masami Hiramatsu 提交于
      Fix variable searching logic to search one in inner than local scope or
      global(CU) scope. In the other words, skip searching in intermediate
      scopes.
      
      e.g., in the following code,
      
      int var1;
      
      void inline infunc(int i)
      {
          i++;   <--- [A]
      }
      
      void func(void)
      {
         int var1, var2;
         infunc(var2);
      }
      
      At [A], "var1" should point the global variable "var1", however, if user
      mis-typed as "var2", variable search should be failed. However, current
      logic searches variable infunc() scope, global scope, and then func()
      scope. Thus, it can find "var2" variable in func() scope. This may not
      be what user expects.
      
      So, it would better not search outer scopes except outermost (compile
      unit) scope which contains only global variables, when it failed to find
      given variable in local scope.
      
      E.g.
      
      Without this:
      $ perf probe -V pre_schedule --externs > without.vars
      
      With this:
      $ perf probe -V pre_schedule --externs > with.vars
      
      Check the diff:
      $ diff without.vars with.vars
      88d87
      <               int     cpu
      133d131
      <               long unsigned int*      switch_count
      
      These vars are actually in the scope of schedule(), the caller of
      pre_schedule().
      
      Cc: Frederic Weisbecker <fweisbec@gmail.com>
      Cc: Ingo Molnar <mingo@elte.hu>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Pekka Enberg <penberg@kernel.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: yrl.pp-manager.tt@hitachi.com
      Link: http://lkml.kernel.org/r/20110811110305.19900.94374.stgit@fedora15Signed-off-by: NMasami Hiramatsu <masami.hiramatsu.pt@hitachi.com>
      Signed-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      f182e3e1
    • M
      perf probe: Fix to search local variables in appropriate scope · 221d0611
      Masami Hiramatsu 提交于
      Fix perf probe to search local variables in appropriate local inlined
      function scope. For example, pre_schedule() has only 2 local variables,
      as below;
      
      $ perf probe -L pre_schedule
      <pre_schedule@/home/mhiramat/ksrc/linux-2.6/kernel/sched.c:0>
            0  static inline void pre_schedule(struct rq *rq, struct task_struct *prev)
               {
            2         if (prev->sched_class->pre_schedule)
            3                 prev->sched_class->pre_schedule(rq, prev);
               }
      
      However, current perf probe shows 4 local variables on pre_schedule(),
      because it searches variables in the caller(schedule()) scope.
      
      $ perf probe -V pre_schedule
      Available variables at pre_schedule
              @<schedule+445>
                      int     cpu
                      long unsigned int*      switch_count
                      struct rq*      rq
                      struct task_struct*     prev
      
      This patch fixes this issue by searching variables in the local scope of
      the instance of inlined function. Here is the result.
      
      $ perf probe -V pre_schedule
      Available variables at pre_schedule
              @<schedule+445>
                      struct rq*      rq
                      struct task_struct*     prev
      
      Cc: Frederic Weisbecker <fweisbec@gmail.com>
      Cc: Ingo Molnar <mingo@elte.hu>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Pekka Enberg <penberg@kernel.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: yrl.pp-manager.tt@hitachi.com
      Link: http://lkml.kernel.org/r/20110811110259.19900.85664.stgit@fedora15Signed-off-by: NMasami Hiramatsu <masami.hiramatsu.pt@hitachi.com>
      Signed-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      221d0611
    • M
      perf probe: Warn when more than one line are given · 13e27d76
      Masami Hiramatsu 提交于
      Check multiple --lines option and print warning informing that only the
      first specified --line option is valid.
      
      Changes from the 1st post:
      
      - Accept only the first option instead of the last.
      - Fix warning message according to David's comment.
      - Mark as a bugfix.
      
      Cc: David Ahern <dsahern@gmail.com>
      Cc: Frederic Weisbecker <fweisbec@gmail.com>
      Cc: Ingo Molnar <mingo@elte.hu>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Pekka Enberg <penberg@kernel.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: yrl.pp-manager.tt@hitachi.com
      Link: http://lkml.kernel.org/r/20110811110253.19900.96192.stgit@fedora15Signed-off-by: NMasami Hiramatsu <masami.hiramatsu.pt@hitachi.com>
      Signed-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      13e27d76
    • M
      perf probe: Fix to walk all inline instances · 36c0c588
      Masami Hiramatsu 提交于
      Fix line-range collector to walk all instances of inlined function,
      because some execution paths can be optimized out depending on the
      function argument of instances.
      
      E.g.)
      inline_func (arg) {
      	if (arg)
      		do_something;
      	else
      		do_another;
      }
      
      func_A() {
      	inline_func(1)
      }
      
      func_B() {
      	inline_func(0)
      }
      
      In this case, func_A may have only do_something code and func_B may have
      only do_another.
      
      Cc: Frederic Weisbecker <fweisbec@gmail.com>
      Cc: Ingo Molnar <mingo@elte.hu>
      Cc: Masami Hiramatsu <masami.hiramatsu@gmail.com>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Pekka Enberg <penberg@kernel.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: yrl.pp-manager.tt@hitachi.com
      Link: http://lkml.kernel.org/r/20110811110247.19900.93702.stgit@fedora15Signed-off-by: NMasami Hiramatsu <masami.hiramatsu@gmail.com>
      Signed-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      36c0c588
    • M
      perf probe: Fix to search nested inlined functions in CU · b0e9cb28
      Masami Hiramatsu 提交于
      Fix perf probe to walk through the lines of all nested inlined function
      call sites and declared lines when a whole CU is passed to the line
      walker.
      
      The die_walk_lines() can have two different type of DIEs, subprogram (or
      inlined-subroutine) DIE and CU DIE.
      
      If a caller passes a subprogram DIE, this means that the walker walk on
      lines of given subprogram. In this case, it just needs to search on
      direct children of DIE tree for finding call-site information of inlined
      function which directly called from given subprogram.
      
      On the other hand, if a caller passes a CU DIE to the walker, this means
      that the walker have to walk on all lines in the source files included
      in given CU DIE. In this case, it has to search whole DIE trees of all
      subprograms to find the call-site information of all nested inlined
      functions.
      
      Without this patch:
      
      $ perf probe --line kernel/cpu.c:151-157
      </home/mhiramat/ksrc/linux-2.6/kernel/cpu.c:151>
      
               static int cpu_notify(unsigned long val, void *v)
               {
          154         return __cpu_notify(val, v, -1, NULL);
               }
      
      With this:
      $ perf probe --line kernel/cpu.c:151-157
      </home/mhiramat/ksrc/linux-2.6/kernel/cpu.c:151>
      
          152  static int cpu_notify(unsigned long val, void *v)
               {
          154         return __cpu_notify(val, v, -1, NULL);
               }
      
      As you can see, --line option with source line range shows the declared
      lines as probe-able.
      
      Cc: Frederic Weisbecker <fweisbec@gmail.com>
      Cc: Ingo Molnar <mingo@elte.hu>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Pekka Enberg <penberg@kernel.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: yrl.pp-manager.tt@hitachi.com
      Link: http://lkml.kernel.org/r/20110811110241.19900.34994.stgit@fedora15Signed-off-by: NMasami Hiramatsu <masami.hiramatsu.pt@hitachi.com>
      Signed-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      b0e9cb28
    • M
      perf probe: Fix line walker to check CU correctly · a128405c
      Masami Hiramatsu 提交于
      Fix line walker to check whether a given DIE is CU or not.
      
      Actually this function accepts CU, subprogram and inlined_subroutine
      DIEs.
      
      Without this fix, perf probe always fails to analyze lines on inlined
      functions;
      
      $ perf probe -L pre_schedule
      Debuginfo analysis failed. (-2)
        Error: Failed to show lines. (-2)
      
      This fixes that bug, as below.
      
      $ perf probe -L pre_schedule
      <pre_schedule@/home/mhiramat/ksrc/linux-2.6/kernel/sched.c:0>
            0  static inline void pre_schedule(struct rq *rq, struct task_struct *prev
               {
            2         if (prev->sched_class->pre_schedule)
            3                 prev->sched_class->pre_schedule(rq, prev);
               }
      
               /* rq->lock is NOT held, but preemption is disabled */
      
      Changes from v1:
       - Update against current tip tree.(Fix dwarf-aux.c)
      
      Cc: Frederic Weisbecker <fweisbec@gmail.com>
      Cc: Ingo Molnar <mingo@elte.hu>
      Cc: Masami Hiramatsu <masami.hiramatsu@gmail.com>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Pekka Enberg <penberg@kernel.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: yrl.pp-manager.tt@hitachi.com
      Link: http://lkml.kernel.org/r/20110811110235.19900.20614.stgit@fedora15Signed-off-by: NMasami Hiramatsu <masami.hiramatsu@gmail.com>
      Signed-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      a128405c
    • M
      perf probe: Fix a memory leak for scopes array · 8afa2a70
      Masami Hiramatsu 提交于
      Fix a memory leak for scopes array when it finds a variable in the
      global scope.
      Reviewed-by: NPekka Enberg <penberg@kernel.org>
      Cc: Frederic Weisbecker <fweisbec@gmail.com>
      Cc: Ingo Molnar <mingo@elte.hu>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Pekka Enberg <penberg@kernel.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: yrl.pp-manager.tt@hitachi.com
      Link: http://lkml.kernel.org/r/20110811110229.19900.63019.stgit@fedora15Signed-off-by: NMasami Hiramatsu <masami.hiramatsu.pt@hitachi.com>
      Signed-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      8afa2a70
    • V
      perf: fix temporary file ownership check · e9b52ef2
      Vasiliy Kulikov 提交于
      A file in /tmp/ might be a symlink, so lstat() should be used instead of
      stat().
      Acked-by: NPekka Enberg <penberg@kernel.org>
      Cc: Frederic Weisbecker <fweisbec@gmail.com>
      Cc: Ingo Molnar <mingo@elte.hu>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Pekka Enberg <penberg@kernel.org>
      Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Link: http://lkml.kernel.org/r/20110811205537.GA22864@albatrosSigned-off-by: NVasiliy Kulikov <segoon@openwall.com>
      Signed-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      e9b52ef2
  4. 11 8月, 2011 1 次提交
    • J
      perf report: Use properly build_id kernel binaries · f57b05ed
      Jiri Olsa 提交于
      If we bring the recorded perf data together with kernel binary from another
      machine using:
      
      	on server A:
      	perf archive
      
      	on server B:
      	tar xjvf perf.data.tar.bz2 -C ~/.debug
      
      the build_id kernel dso is not properly recognized during the "perf report"
      command on server B.
      
      The reason is, that build_id dsos are added during the session initialization,
      while the kernel maps are created during the sample event processing.
      
      The machine__create_kernel_maps functions ends up creating new dso object for
      kernel, but it does not check if we already have one added by build_id
      processing.
      
      Also the build_id reading ABI quirk added in commit:
      
       - commit b2511481
         perf build-id: Add quirk to deal with perf.data file format breakage
      
      populates the "struct build_id_event::pid" with 0, which
      is later interpreted as DEFAULT_GUEST_KERNEL_ID.
      
      This is not always correct, so it's better to guess the pid
      value based on the "struct build_id_event::header::misc" value.
      
      - Tested with data generated on x86 kernel version v2.6.34
        and reported back on x86_64 current kernel.
      - Not tested for guest kernel case.
      
      Note the problem stays for PERF_RECORD_MMAP events recorded by perf that
      does not use proper pid (HOST_KERNEL_ID/DEFAULT_GUEST_KERNEL_ID). They are
      misinterpreted within the current perf code. Probably there's not much we
      can do about that.
      
      Cc: Avi Kivity <avi@redhat.com>
      Cc: Frederic Weisbecker <fweisbec@gmail.com>
      Cc: Ingo Molnar <mingo@elte.hu>
      Cc: Yanmin Zhang <yanmin_zhang@linux.intel.com>
      Link: http://lkml.kernel.org/r/20110601194346.GB1934@jolsa.brq.redhat.comSigned-off-by: NJiri Olsa <jolsa@redhat.com>
      Signed-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      f57b05ed
  5. 10 8月, 2011 4 次提交
  6. 09 8月, 2011 1 次提交
  7. 08 8月, 2011 5 次提交
  8. 03 8月, 2011 1 次提交
  9. 26 7月, 2011 1 次提交
  10. 25 7月, 2011 1 次提交
  11. 22 7月, 2011 1 次提交
  12. 21 7月, 2011 3 次提交