1. 25 11月, 2016 4 次提交
    • A
      perf annotate: Improve support for ARM · acc9bfb5
      Arnaldo Carvalho de Melo 提交于
      By using arch->init() to set up some regular expressions to associate
      ins_ops to ARM instructions, ditching that old table that has
      instructions not present on ARM.
      
      Take advantage of having an arch->init() to hide more arm specific stuff
      from the common code, like the objdump details.
      
      The regular expressions comes from a patch written by Kim Phillips.
      Reviewed-by: NRavi Bangoria <ravi.bangoria@linux.vnet.ibm.com>
      Cc: Adrian Hunter <adrian.hunter@intel.com>
      Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
      Cc: Chris Riyder <chris.ryder@arm.com>
      Cc: David Ahern <dsahern@gmail.com>
      Cc: Jiri Olsa <jolsa@kernel.org>
      Cc: Kim Phillips <kim.phillips@arm.com>
      Cc: Markus Trippelsdorf <markus@trippelsdorf.de>
      Cc: Masami Hiramatsu <mhiramat@kernel.org>
      Cc: Namhyung Kim <namhyung@kernel.org>
      Cc: Naveen N. Rao <naveen.n.rao@linux.vnet.ibm.com>
      Cc: Pawel Moll <pawel.moll@arm.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Russell King <rmk+kernel@arm.linux.org.uk>
      Cc: Taeung Song <treeze.taeung@gmail.com>
      Cc: Wang Nan <wangnan0@huawei.com>
      Link: http://lkml.kernel.org/n/tip-77m7lufz9ajjimkrebtg5ead@git.kernel.orgSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      acc9bfb5
    • A
      perf annotate: Allow arches to have a init routine and a priv area · 0781ea92
      Arnaldo Carvalho de Melo 提交于
      Arches like ARM will want to use regular expressions when deciding what
      instructions to associate with what ins_ops, provide infrastructure for
      that.
      Reviewed-by: NRavi Bangoria <ravi.bangoria@linux.vnet.ibm.com>
      Cc: Adrian Hunter <adrian.hunter@intel.com>
      Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
      Cc: Chris Riyder <chris.ryder@arm.com>
      Cc: David Ahern <dsahern@gmail.com>
      Cc: Jiri Olsa <jolsa@kernel.org>
      Cc: Kim Phillips <kim.phillips@arm.com>
      Cc: Markus Trippelsdorf <markus@trippelsdorf.de>
      Cc: Masami Hiramatsu <mhiramat@kernel.org>
      Cc: Namhyung Kim <namhyung@kernel.org>
      Cc: Naveen N. Rao <naveen.n.rao@linux.vnet.ibm.com>
      Cc: Pawel Moll <pawel.moll@arm.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Russell King <rmk+kernel@arm.linux.org.uk>
      Cc: Taeung Song <treeze.taeung@gmail.com>
      Cc: Wang Nan <wangnan0@huawei.com>
      Link: http://lkml.kernel.org/n/tip-7dmnk9el2ipu3nxog092k9z5@git.kernel.orgSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      0781ea92
    • A
      perf annotate: Introduce alternative method of keeping instructions table · 2a1ff812
      Arnaldo Carvalho de Melo 提交于
      Some arches may want to dynamically populate the table using regular
      expressions on the instruction names to associate them with a set of
      parsing/formatting/etc functions (struct ins_ops), so provide a fallback
      for when the ins__find() method fails.
      
      That fall back will be able to resize the arch->instructions, setting
      arch->nr_instructions appropriately, helper functions to associate an
      ins_ops to an instruction name, growing the arch->instructions if needed
      and resorting it are provided, all the arch specific callback needs to
      do is to decide if the missing instruction should be added to
      arch->instructions with a ins_ops association.
      Reviewed-by: NRavi Bangoria <ravi.bangoria@linux.vnet.ibm.com>
      Cc: Adrian Hunter <adrian.hunter@intel.com>
      Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
      Cc: Chris Riyder <chris.ryder@arm.com>
      Cc: David Ahern <dsahern@gmail.com>
      Cc: Jiri Olsa <jolsa@kernel.org>
      Cc: Kim Phillips <kim.phillips@arm.com>
      Cc: Markus Trippelsdorf <markus@trippelsdorf.de>
      Cc: Masami Hiramatsu <mhiramat@kernel.org>
      Cc: Namhyung Kim <namhyung@kernel.org>
      Cc: Naveen N. Rao <naveen.n.rao@linux.vnet.ibm.com>
      Cc: Pawel Moll <pawel.moll@arm.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Russell King <rmk+kernel@arm.linux.org.uk>
      Cc: Taeung Song <treeze.taeung@gmail.com>
      Cc: Wang Nan <wangnan0@huawei.com>
      Link: http://lkml.kernel.org/n/tip-auu13yradxf7g5dgtpnzt97a@git.kernel.orgSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      2a1ff812
    • A
      perf annotate: Remove duplicate 'name' field from disasm_line · 75b49202
      Arnaldo Carvalho de Melo 提交于
      The disasm_line::name field is always equal to ins::name, being used
      just to locate the instruction's ins_ops from the per-arch instructions
      table.
      
      Eliminate this duplication, nuking that field and instead make
      ins__find() return an ins_ops, store it in disasm_line::ins.ops, and
      keep just in disasm_line::ins.name what was in disasm_line::name, this
      way we end up not keeping a reference to entries in the per-arch
      instructions table.
      
      This in turn will help supporting multiple ways to manage the per-arch
      instructions table, allowing resorting that array, for instance, when
      the entries will move after references to its addresses were made. The
      same problem is avoided when one grows the array with realloc.
      
      So architectures simply keeping a constant array will work as well as
      architectures building the table using regular expressions or other
      logic that involves resorting the table.
      Reviewed-by: NRavi Bangoria <ravi.bangoria@linux.vnet.ibm.com>
      Cc: Adrian Hunter <adrian.hunter@intel.com>
      Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
      Cc: Chris Riyder <chris.ryder@arm.com>
      Cc: David Ahern <dsahern@gmail.com>
      Cc: Jiri Olsa <jolsa@kernel.org>
      Cc: Kim Phillips <kim.phillips@arm.com>
      Cc: Markus Trippelsdorf <markus@trippelsdorf.de>
      Cc: Masami Hiramatsu <mhiramat@kernel.org>
      Cc: Namhyung Kim <namhyung@kernel.org>
      Cc: Naveen N. Rao <naveen.n.rao@linux.vnet.ibm.com>
      Cc: Pawel Moll <pawel.moll@arm.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Russell King <rmk+kernel@arm.linux.org.uk>
      Cc: Taeung Song <treeze.taeung@gmail.com>
      Cc: Wang Nan <wangnan0@huawei.com>
      Link: http://lkml.kernel.org/n/tip-vr899azvabnw9gtuepuqfd9t@git.kernel.orgSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      75b49202
  2. 18 11月, 2016 3 次提交
    • A
      perf annotate: Add per arch instructions annotate handlers · 763d8960
      Arnaldo Carvalho de Melo 提交于
      Another step in supporting cross annotation.
      
      The arch specific tables are put in:
      
         tools/perf/arch/$ARCH/annotation/instructions.c
      
      which, so far, just plug instructions to a bunch of parsers/formatters,
      but may have more as the need arises.
      
      This is an alternative implementation to a previous attempt made by Ravi
      Bangoria.
      
      Cc: Adrian Hunter <adrian.hunter@intel.com>
      Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
      Cc: Chris Riyder <chris.ryder@arm.com>
      Cc: David Ahern <dsahern@gmail.com>
      Cc: Jiri Olsa <jolsa@kernel.org>
      Cc: Kim Phillips <kim.phillips@arm.com>
      Cc: Markus Trippelsdorf <markus@trippelsdorf.de>
      Cc: Masami Hiramatsu <mhiramat@kernel.org>
      Cc: Namhyung Kim <namhyung@kernel.org>
      Cc: Naveen N. Rao <naveen.n.rao@linux.vnet.ibm.com>
      Cc: Pawel Moll <pawel.moll@arm.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Ravi Bangoria <ravi.bangoria@linux.vnet.ibm.com>
      Cc: Russell King <rmk+kernel@arm.linux.org.uk>
      Cc: Taeung Song <treeze.taeung@gmail.com>
      Cc: Wang Nan <wangnan0@huawei.com>
      Link: http://lkml.kernel.org/n/tip-g3wt282lfa51j4qd0813e3az@git.kernel.orgSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      763d8960
    • A
      perf annotate: Allow arches to specify functions to skip · 9c2fb451
      Arnaldo Carvalho de Melo 提交于
      This is to cope with an ARM specific kludge introduced in the original
      patch supporting ARM annotation, cfef25b8 ("perf annotate: ARM
      support") that made functions with a '+' in its name to be skipped when
      processing call instructions.
      
      With this patchkit it should be possible to collect a perf.data file on
      a ARM machine and then annotate it on a x86 workstation and have those
      ARM kludges used.
      
      Cc: Adrian Hunter <adrian.hunter@intel.com>
      Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
      Cc: Chris Riyder <chris.ryder@arm.com>
      Cc: David Ahern <dsahern@gmail.com>
      Cc: Jiri Olsa <jolsa@kernel.org>
      Cc: Kim Phillips <kim.phillips@arm.com>
      Cc: Markus Trippelsdorf <markus@trippelsdorf.de>
      Cc: Masami Hiramatsu <mhiramat@kernel.org>
      Cc: Namhyung Kim <namhyung@kernel.org>
      Cc: Naveen N. Rao <naveen.n.rao@linux.vnet.ibm.com>
      Cc: Pawel Moll <pawel.moll@arm.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Ravi Bangoria <ravi.bangoria@linux.vnet.ibm.com>
      Cc: Russell King <rmk+kernel@arm.linux.org.uk>
      Cc: Taeung Song <treeze.taeung@gmail.com>
      Cc: Wang Nan <wangnan0@huawei.com>
      Link: http://lkml.kernel.org/n/tip-2fi3sy7q3sssdi7m7cbe07gy@git.kernel.orgSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      9c2fb451
    • A
      perf annotate: Start supporting cross arch annotation · 786c1b51
      Arnaldo Carvalho de Melo 提交于
      Introduce a 'struct arch', where arch specific stuff will live, starting
      with objdump's choice of comment delimitation character, that is '#' in
      x86 while a ';' in arm.
      
      This has some bits and pieces from a patch submitted by Ravi.
      
      Cc: Adrian Hunter <adrian.hunter@intel.com>
      Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
      Cc: Chris Riyder <chris.ryder@arm.com>
      Cc: David Ahern <dsahern@gmail.com>
      Cc: Jiri Olsa <jolsa@kernel.org>
      Cc: Kim Phillips <kim.phillips@arm.com>
      Cc: Markus Trippelsdorf <markus@trippelsdorf.de>
      Cc: Masami Hiramatsu <mhiramat@kernel.org>
      Cc: Namhyung Kim <namhyung@kernel.org>
      Cc: Naveen N. Rao <naveen.n.rao@linux.vnet.ibm.com>
      Cc: Pawel Moll <pawel.moll@arm.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Ravi Bangoria <ravi.bangoria@linux.vnet.ibm.com>
      Cc: Taeung Song <treeze.taeung@gmail.com>
      Cc: Wang Nan <wangnan0@huawei.com>
      Link: http://lkml.kernel.org/n/tip-f337tzjjcl8vtapgvjxmhrbx@git.kernel.orgSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      786c1b51
  3. 20 9月, 2016 3 次提交
    • A
      perf annotate: Resolve 'call' operands to function names · 5f62d4fd
      Arnaldo Carvalho de Melo 提交于
      Before this patch the '_raw_spin_lock_irqsave' and 'update_rq_clock' operands
      were appearing just as hexadecimal numbers:
      
        update_blocked_averages  /proc/kcore
             │       push   %r12
             │       push   %rbx
             │       and    $0xfffffffffffffff0,%rsp
             │       sub    $0x40,%rsp
             │       add    -0x662cac00(,%rdi,8),%rax
             │       mov    %rax,%rbx
             │       mov    %rax,%rdi
             │       mov    %rax,0x38(%rsp)
             │     → callq  _raw_spin_lock_irqsave
             │       mov    %rbx,%rdi
             │       mov    %rax,0x30(%rsp)
             │     → callq  update_rq_clock
             │       mov    0x8d0(%rbx),%rax
             │       lea    0x8d0(%rbx),%r11
      
      To check that all is right one can always use the 'o' hotkey and see
      the original objdump -dS output, that for this case is:
      
        update_blocked_averages  /proc/kcore
             │ffffffff990d5489:   push   %r12
             │ffffffff990d548b:   push   %rbx
             │ffffffff990d548c:   and    $0xfffffffffffffff0,%rsp
             │ffffffff990d5490:   sub    $0x40,%rsp
             │ffffffff990d5494:   add    -0x662cac00(,%rdi,8),%rax
             │ffffffff990d549c:   mov    %rax,%rbx
             │ffffffff990d549f:   mov    %rax,%rdi
             │ffffffff990d54a2:   mov    %rax,0x38(%rsp)
             │ffffffff990d54a7: → callq  0xffffffff997eb7a0
             │ffffffff990d54ac:   mov    %rbx,%rdi
             │ffffffff990d54af:   mov    %rax,0x30(%rsp)
             │ffffffff990d54b4: → callq  0xffffffff990c7720
             │ffffffff990d54b9:   mov    0x8d0(%rbx),%rax
             │ffffffff990d54c0:   lea    0x8d0(%rbx),%r11
      
      Use the 'h' hotkey to see a list of available hotkeys.
      
      More work needed to cover operands for other instructions, such as 'mov',
      that can resolve variable names, etc.
      
      Cc: Adrian Hunter <adrian.hunter@intel.com>
      Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
      Cc: Chris Riyder <chris.ryder@arm.com>
      Cc: David Ahern <dsahern@gmail.com>
      Cc: Hemant Kumar <hemant@linux.vnet.ibm.com>
      Cc: Jiri Olsa <jolsa@kernel.org>
      Cc: Markus Trippelsdorf <markus@trippelsdorf.de>
      Cc: Masami Hiramatsu <mhiramat@kernel.org>
      Cc: Michael Ellerman <mpe@ellerman.id.au>
      Cc: Namhyung Kim <namhyung@kernel.org>
      Cc: Naveen N. Rao <naveen.n.rao@linux.vnet.ibm.com>
      Cc: Pawel Moll <pawel.moll@arm.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Ravi Bangoria <ravi.bangoria@linux.vnet.ibm.com>
      Cc: Russell King <rmk+kernel@arm.linux.org.uk>
      Cc: Taeung Song <treeze.taeung@gmail.com>
      Cc: Wang Nan <wangnan0@huawei.com>
      Link: http://lkml.kernel.org/n/tip-xqgtw9mzmzcjgwkis9kiiv1p@git.kernel.orgSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      5f62d4fd
    • A
      perf annotate: Pass the symbol's map/dso to the instruction parsers · bff5c306
      Arnaldo Carvalho de Melo 提交于
      So that things like:
      
             → callq  0xffffffff993e3230
      
      found while disassembling /proc/kcore can be beautified by later
      patches, that will resolve that address to a function, looking it up in
      /proc/kallsyms.
      
      Cc: Adrian Hunter <adrian.hunter@intel.com>
      Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
      Cc: Chris Riyder <chris.ryder@arm.com>
      Cc: David Ahern <dsahern@gmail.com>
      Cc: Hemant Kumar <hemant@linux.vnet.ibm.com>
      Cc: Jiri Olsa <jolsa@kernel.org>
      Cc: Markus Trippelsdorf <markus@trippelsdorf.de>
      Cc: Masami Hiramatsu <mhiramat@kernel.org>
      Cc: Michael Ellerman <mpe@ellerman.id.au>
      Cc: Namhyung Kim <namhyung@kernel.org>
      Cc: Naveen N. Rao <naveen.n.rao@linux.vnet.ibm.com>
      Cc: Pawel Moll <pawel.moll@arm.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Ravi Bangoria <ravi.bangoria@linux.vnet.ibm.com>
      Cc: Russell King <rmk+kernel@arm.linux.org.uk>
      Cc: Taeung Song <treeze.taeung@gmail.com>
      Cc: Wang Nan <wangnan0@huawei.com>
      Link: http://lkml.kernel.org/n/tip-p76myuke4j7gplg54amaklxk@git.kernel.orgSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      bff5c306
    • R
      perf annotate: Do not ignore call instruction with indirect target · 88a7fcf9
      Ravi Bangoria 提交于
      Do not ignore call instruction with indirect target when its already
      identified as a call. This is an extension of commit e8ea1561 ("perf
      annotate: Use raw form for register indirect call instructions") to
      generalize annotation for all instructions with indirect calls.
      
      This is needed for certain powerpc call instructions that use address in
      a register (such as bctrl, btarl, ...).
      
      Apart from that, when kcore is used to disassemble function, all call
      instructions were ignored. This patch will fix it as a side effect by
      not ignoring them. For example,
      
      Before (with kcore):
             mov    %r13,%rdi
             callq  0xffffffff811a7e70
           ^ jmpq   64
             mov    %gs:0x7ef41a6e(%rip),%al
      
      After (with kcore):
             mov    %r13,%rdi
           > callq  0xffffffff811a7e70
           ^ jmpq   64
             mov    %gs:0x7ef41a6e(%rip),%al
      Suggested-by: NMichael Ellerman <mpe@ellerman.id.au>
      [Suggested about 'bctrl' instruction]
      Signed-off-by: NRavi Bangoria <ravi.bangoria@linux.vnet.ibm.com>
      Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
      Cc: Chris Riyder <chris.ryder@arm.com>
      Cc: Hemant Kumar <hemant@linux.vnet.ibm.com>
      Cc: Jiri Olsa <jolsa@kernel.org>
      Cc: Markus Trippelsdorf <markus@trippelsdorf.de>
      Cc: Masami Hiramatsu <mhiramat@kernel.org>
      Cc: Namhyung Kim <namhyung@kernel.org>
      Cc: Naveen N. Rao <naveen.n.rao@linux.vnet.ibm.com>
      Cc: Pawel Moll <pawel.moll@arm.com>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Cc: Russell King <rmk+kernel@arm.linux.org.uk>
      Cc: Taeung Song <treeze.taeung@gmail.com>
      Link: http://lkml.kernel.org/r/1471611578-11255-5-git-send-email-ravi.bangoria@linux.vnet.ibm.comSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      88a7fcf9
  4. 09 9月, 2016 1 次提交
    • P
      perf annotate: Add branch stack / basic block · 70fbe057
      Peter Zijlstra 提交于
      I wanted to know the hottest path through a function and figured the
      branch-stack (LBR) information should be able to help out with that.
      
      The below uses the branch-stack to create basic blocks and generate
      statistics from them.
      
              from    to              branch_i
              * ----> *
                      |
                      | block
                      v
                      * ----> *
                      from    to      branch_i+1
      
      The blocks are broken down into non-overlapping ranges, while tracking
      if the start of each range is an entry point and/or the end of a range
      is a branch.
      
      Each block iterates all ranges it covers (while splitting where required
      to exactly match the block) and increments the 'coverage' count.
      
      For the range including the branch we increment the taken counter, as
      well as the pred counter if flags.predicted.
      
      Using these number we can find if an instruction:
      
       - had coverage; given by:
      
              br->coverage / br->sym->max_coverage
      
         This metric ensures each symbol has a 100% spot, which reflects the
         observation that each symbol must have a most covered/hottest
         block.
      
       - is a branch target: br->is_target && br->start == add
      
       - for targets, how much of a branch's coverages comes from it:
      
      	target->entry / branch->coverage
      
       - is a branch: br->is_branch && br->end == addr
      
       - for branches, how often it was taken:
      
              br->taken / br->coverage
      
         after all, all execution that didn't take the branch would have
         incremented the coverage and continued onward to a later branch.
      
       - for branches, how often it was predicted:
      
              br->pred / br->taken
      
      The coverage percentage is used to color the address and asm sections;
      for low (<1%) coverage we use NORMAL (uncolored), indicating that these
      instructions are not 'important'. For high coverage (>75%) we color the
      address RED.
      
      For each branch, we add an asm comment after the instruction with
      information on how often it was taken and predicted.
      
      Output looks like (sans color, which does loose a lot of the
      information :/)
      
      $ perf record --branch-filter u,any -e cycles:p ./branches 27
      $ perf annotate branches
      
       Percent |	Source code & Disassembly of branches for cycles:pu (217 samples)
      ---------------------------------------------------------------------------------
               :	branches():
          0.00 :	  40057a:       push   %rbp
          0.00 :	  40057b:       mov    %rsp,%rbp
          0.00 :	  40057e:       sub    $0x20,%rsp
          0.00 :	  400582:       mov    %rdi,-0x18(%rbp)
          0.00 :	  400586:       mov    %rsi,-0x20(%rbp)
          0.00 :	  40058a:       mov    -0x18(%rbp),%rax
          0.00 :	  40058e:       mov    %rax,-0x10(%rbp)
          0.00 :	  400592:       movq   $0x0,-0x8(%rbp)
          0.00 :	  40059a:       jmpq   400656 <branches+0xdc>
          1.84 :	  40059f:       mov    -0x10(%rbp),%rax	# +100.00%
          3.23 :	  4005a3:       and    $0x1,%eax
          1.84 :	  4005a6:       test   %rax,%rax
          0.00 :	  4005a9:       je     4005bf <branches+0x45>	# -54.50% (p:42.00%)
          0.46 :	  4005ab:       mov    0x200bbe(%rip),%rax        # 601170 <acc>
         12.90 :	  4005b2:       add    $0x1,%rax
          2.30 :	  4005b6:       mov    %rax,0x200bb3(%rip)        # 601170 <acc>
          0.46 :	  4005bd:       jmp    4005d1 <branches+0x57>	# -100.00% (p:100.00%)
          0.92 :	  4005bf:       mov    0x200baa(%rip),%rax        # 601170 <acc>	# +49.54%
         13.82 :	  4005c6:       sub    $0x1,%rax
          0.46 :	  4005ca:       mov    %rax,0x200b9f(%rip)        # 601170 <acc>
          2.30 :	  4005d1:       mov    -0x10(%rbp),%rax	# +50.46%
          0.46 :	  4005d5:       mov    %rax,%rdi
          0.46 :	  4005d8:       callq  400526 <lfsr>	# -100.00% (p:100.00%)
          0.00 :	  4005dd:       mov    %rax,-0x10(%rbp)	# +100.00%
          0.92 :	  4005e1:       mov    -0x18(%rbp),%rax
          0.00 :	  4005e5:       and    $0x1,%eax
          0.00 :	  4005e8:       test   %rax,%rax
          0.00 :	  4005eb:       je     4005ff <branches+0x85>	# -100.00% (p:100.00%)
          0.00 :	  4005ed:       mov    0x200b7c(%rip),%rax        # 601170 <acc>
          0.00 :	  4005f4:       shr    $0x2,%rax
          0.00 :	  4005f8:       mov    %rax,0x200b71(%rip)        # 601170 <acc>
          0.00 :	  4005ff:       mov    -0x10(%rbp),%rax	# +100.00%
          7.37 :	  400603:       and    $0x1,%eax
          3.69 :	  400606:       test   %rax,%rax
          0.00 :	  400609:       jne    400612 <branches+0x98>	# -59.25% (p:42.99%)
          1.84 :	  40060b:       mov    $0x1,%eax
         14.29 :	  400610:       jmp    400617 <branches+0x9d>	# -100.00% (p:100.00%)
          1.38 :	  400612:       mov    $0x0,%eax	# +57.65%
         10.14 :	  400617:       test   %al,%al	# +42.35%
          0.00 :	  400619:       je     40062f <branches+0xb5>	# -57.65% (p:100.00%)
          0.46 :	  40061b:       mov    0x200b4e(%rip),%rax        # 601170 <acc>
          2.76 :	  400622:       sub    $0x1,%rax
          0.00 :	  400626:       mov    %rax,0x200b43(%rip)        # 601170 <acc>
          0.46 :	  40062d:       jmp    400641 <branches+0xc7>	# -100.00% (p:100.00%)
          0.92 :	  40062f:       mov    0x200b3a(%rip),%rax        # 601170 <acc>	# +56.13%
          2.30 :	  400636:       add    $0x1,%rax
          0.92 :	  40063a:       mov    %rax,0x200b2f(%rip)        # 601170 <acc>
          0.92 :	  400641:       mov    -0x10(%rbp),%rax	# +43.87%
          2.30 :	  400645:       mov    %rax,%rdi
          0.00 :	  400648:       callq  400526 <lfsr>	# -100.00% (p:100.00%)
          0.00 :	  40064d:       mov    %rax,-0x10(%rbp)	# +100.00%
          1.84 :	  400651:       addq   $0x1,-0x8(%rbp)
          0.92 :	  400656:       mov    -0x8(%rbp),%rax
          5.07 :	  40065a:       cmp    -0x20(%rbp),%rax
          0.00 :	  40065e:       jb     40059f <branches+0x25>	# -100.00% (p:100.00%)
          0.00 :	  400664:       nop
          0.00 :	  400665:       leaveq
          0.00 :	  400666:       retq
      
      (Note: the --branch-filter u,any was used to avoid spurious target and
      branch points due to interrupts/faults, they show up as very small -/+
      annotations on 'weird' locations)
      
      Committer note:
      
      Please take a look at:
      
        http://vger.kernel.org/~acme/perf/annotate_basic_blocks.png
      
      To see the colors.
      Signed-off-by: NPeter Zijlstra (Intel) <peterz@infradead.org>
      Tested-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      Cc: Alexander Shishkin <alexander.shishkin@linux.intel.com>
      Cc: Andi Kleen <andi@firstfloor.org>
      Cc: Anshuman Khandual <khandual@linux.vnet.ibm.com>
      Cc: David Carrillo-Cisneros <davidcc@google.com>
      Cc: Jiri Olsa <jolsa@kernel.org>
      Cc: Kan Liang <kan.liang@intel.com>
      Cc: Linus Torvalds <torvalds@linux-foundation.org>
      Cc: Namhyung Kim <namhyung@kernel.org>
      Cc: Stephane Eranian <eranian@google.com>
      [ Moved sym->max_coverage to 'struct annotate', aka symbol__annotate(sym) ]
      Signed-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      70fbe057
  5. 05 9月, 2016 1 次提交
  6. 30 8月, 2016 1 次提交
  7. 24 8月, 2016 3 次提交
  8. 02 8月, 2016 3 次提交
  9. 29 7月, 2016 1 次提交
  10. 01 7月, 2016 1 次提交
  11. 30 6月, 2016 1 次提交
  12. 28 6月, 2016 1 次提交
  13. 27 6月, 2016 1 次提交
  14. 20 5月, 2016 2 次提交
  15. 17 5月, 2016 1 次提交
  16. 12 5月, 2016 1 次提交
  17. 06 5月, 2016 1 次提交
  18. 08 12月, 2015 1 次提交
  19. 12 11月, 2015 1 次提交
    • M
      perf annotate: Support full source file paths for srcline fix · 4a4c03c1
      Michael Petlan 提交于
      The --full-paths option did not show the full source file paths in the 'perf
      annotate' tool, because the value of the option was not propagated into the
      related functions.
      
      With this patch the value of the --full-paths option is known to the function
      that composes the srcline string, so it prints the full path when necessary.
      
      Committer Note:
      
      This affects annotate when the --print-line option is used:
      
        # perf annotate -h 2>&1 | grep print-line
            -l, --print-line      print matching source lines (may be slow)
      
      Looking just at the lines that should be affected by this change:
      
      Before:
      
        # perf annotate --print-line --full-paths --stdio fput | grep '\.[ch]:[0-9]\+'
           94.44 atomic64_64.h:114
            5.56 file_table.c:265
         file_table.c:265    5.56 :	  ffffffff81219a00:       callq  ffffffff81769360 <__fentry__>
         atomic64_64.h:114   94.44 :	  ffffffff81219a05:       lock decq 0x38(%rdi)
      
      After:
      
        # perf annotate --print-line --full-paths --stdio fput | grep '\.[ch]:[0-9]\+'
           94.44 /home/git/linux/arch/x86/include/asm/atomic64_64.h:114
            5.56 /home/git/linux/fs/file_table.c:265
         /home/git/linux/fs/file_table.c:265    5.56 :	  ffffffff81219a00:       callq  ffffffff81769360 <__fentry__>
         /home/git/linux/arch/x86/include/asm/atomic64_64.h:114   94.44 :	  ffffffff81219a05:       lock decq 0x38(%rdi)
        #
      Signed-off-by: NMichael Petlan <mpetlan@redhat.com>
      Tested-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      Link: http://permalink.gmane.org/gmane.linux.kernel.perf.user/2365Signed-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      4a4c03c1
  20. 06 11月, 2015 1 次提交
    • A
      perf annotate: Inform the user about objdump failures in --stdio · 62ec9b3f
      Andi Kleen 提交于
      When the browser fails to annotate it is difficult for users to find out
      what went wrong.
      
      Add some errors for objdump failures that are displayed in the UI.
      
      Note it would be even better to handle these errors smarter, like
      falling back to the binary when the debug info is somehow corrupted. But
      for now just giving a better error is an improvement.
      
      Committer note:
      
      This works for --stdio, where errors just scroll by the screen:
      
        # perf annotate --stdio intel_idle
        Failure running objdump  --start-address=0xffffffff81418290 --stop-address=0xffffffff814183ae -l -d --no-show-raw -S -C /root/.debug/.build-id/28/2777c262e6b3c0451375163c9a81c893218ab1 2>/dev/null|grep -v /root/.debug/.build-id/28/2777c262e6b3c0451375163c9a81c893218ab1|expand
         Percent |      Source code & Disassembly of vmlinux for cycles:pp
        ------------------------------------------------------------------
      
      And with that one can use that command line to try to find out more about what
      happened instead of getting a blank screen, an improvement.
      
      We need tho to improve this further to get it to work with other UIs, like
      --tui and --gtk, where it continues showing a blank screen, no messages, as
      the pr_err() used is enough just for --stdio.
      Signed-off-by: NAndi Kleen <ak@linux.intel.com>
      Tested-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      Cc: Jiri Olsa <jolsa@kernel.org>
      Cc: Namhyung Kim <namhyung@kernel.org>
      Link: http://lkml.kernel.org/r/1446779167-18949-1-git-send-email-andi@firstfloor.orgSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      62ec9b3f
  21. 22 10月, 2015 1 次提交
  22. 21 8月, 2015 1 次提交
  23. 17 8月, 2015 1 次提交
    • A
      perf annotate: Fix 32-bit compilation error in util/annotate.c · 3d7245b0
      Adrian Hunter 提交于
      Fix the following 32-bit compilation errors:
      
        util/annotate.c: In function ‘addr_map_symbol__account_cycles’:
        util/annotate.c:643:3: error: format ‘%lx’ expects argument of type ‘long unsigned int’, but argument 4 has type ‘u64’ [-Werror=format=]
          pr_debug2("BB with bad start: addr %lx start %lx sym %lx saddr %lx\n",
            ^
        util/annotate.c:643:3: error: format ‘%lx’ expects argument of type ‘long unsigned int’, but argument 5 has type ‘u64’ [-Werror=format=]
        util/annotate.c:643:3: error: format ‘%lx’ expects argument of type ‘long unsigned int’, but argument 6 has type ‘u64’ [-Werror=format=]
      
      These were introduced by the patch:
      
      "perf report: Add infrastructure for a cycles histogram"
      
      Also change the 'saddr' variable from 'unsigned long' to 'u64'
      noting that theoretically we could be processing data captured
      on a 64-bit machine but processing it on a 32-bit machine.
      Signed-off-by: NAdrian Hunter <adrian.hunter@intel.com>
      Cc: Andi Kleen <ak@linux.intel.com>
      Cc: Jiri Olsa <jolsa@redhat.com>
      Fixes: d4957633 ("perf report: Add infrastructure for a cycles histogram")
      Link: http://lkml.kernel.org/r/1439536294-18241-1-git-send-email-adrian.hunter@intel.comSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      3d7245b0
  24. 07 8月, 2015 1 次提交
  25. 20 6月, 2015 2 次提交
  26. 28 5月, 2015 1 次提交
  27. 23 3月, 2015 1 次提交