1. 08 Feb, 2024 1 commit
    • Adrian Hunter's avatar
      perf tools: Make it possible to see perf's kernel and module memory mappings · 0bdfbd04
      Adrian Hunter authored
      Dump kmaps if using 'perf --debug kmaps' or verbose > 2 (e.g. -vvv) for
      tools 'perf script' and 'perf report' if there is no browser.
      
      Example:
      
        $ perf --debug kmaps script 2>&1 >/dev/null | grep kvm.intel
        build id event received for /lib/modules/6.7.2-local/kernel/arch/x86/kvm/kvm-intel.ko: 0691d75e10e72ebbbd45a44c59f6d00a5604badf [20]
        Map: 0-3a3 4f5d8 [kvm_intel].modinfo
        Map: 0-5240 5f280 [kvm_intel]__versions
        Map: 0-30 64 [kvm_intel].note.Linux
        Map: 0-14 644c0 [kvm_intel].orc_header
        Map: 0-5297 43680 [kvm_intel].rodata
        Map: 0-5bee 3b837 [kvm_intel].text.unlikely
        Map: 0-7e0 41430 [kvm_intel].noinstr.text
        Map: 0-2080 713c0 [kvm_intel].bss
        Map: 0-26 705c8 [kvm_intel].data..read_mostly
        Map: 0-5888 6a4c0 [kvm_intel].data
        Map: 0-22 70220 [kvm_intel].data.once
        Map: 0-40 705f0 [kvm_intel].data..percpu
        Map: 0-1685 41d20 [kvm_intel].init.text
        Map: 0-4b8 6fd60 [kvm_intel].init.data
        Map: 0-380 70248 [kvm_intel]__dyndbg
        Map: 0-8 70218 [kvm_intel].exit.data
        Map: 0-438 4f980 [kvm_intel]__param
        Map: 0-5f5 4ca0f [kvm_intel].rodata.str1.1
        Map: 0-3657 493b8 [kvm_intel].rodata.str1.8
        Map: 0-e0 70640 [kvm_intel].data..ro_after_init
        Map: 0-500 70ec0 [kvm_intel].gnu.linkonce.this_module
        Map: ffffffffc13a7000-ffffffffc1421000 a0 /lib/modules/6.7.2-local/kernel/arch/x86/kvm/kvm-intel.ko
      
      The example above shows how the module section mappings are all wrong
      except for the main .text mapping at 0xffffffffc13a7000.
      Signed-off-by: default avatarAdrian Hunter <adrian.hunter@intel.com>
      Acked-by: default avatarNamhyung Kim <namhyung@kernel.org>
      Cc: Like Xu <like.xu.linux@gmail.com>
      Signed-off-by: default avatarNamhyung Kim <namhyung@kernel.org>
      Link: https://lore.kernel.org/r/20240208085326.13432-2-adrian.hunter@intel.com
      0bdfbd04
  2. 07 Feb, 2024 3 commits
    • Namhyung Kim's avatar
      perf record: Display data size on pipe mode · 5b9e4eef
      Namhyung Kim authored
      Currently pipe mode doesn't set the file size and it results in a
      misleading message of 0 data size at the end.  Although it might miss
      some accounting for pipe header or more, just displaying the data size
      would reduce the possible confusion.
      
      Before:
        $ perf record -o- perf test -w noploop | perf report -i- -q --percent-limit=1
        [ perf record: Woken up 1 times to write data ]
        [ perf record: Captured and wrote 0.000 MB - ]    <======  (here)
            99.58%  perf     perf                  [.] noploop
      
      After:
        $ perf record -o- perf test -w noploop | perf report -i- -q --percent-limit=1
        [ perf record: Woken up 1 times to write data ]
        [ perf record: Captured and wrote 0.229 MB - ]
            99.46%  perf     perf                  [.] noploop
      Signed-off-by: default avatarNamhyung Kim <namhyung@kernel.org>
      Reviewed-by: default avatarIan Rogers <irogers@google.com>
      Link: https://lore.kernel.org/r/20240112231340.779469-1-namhyung@kernel.org
      5b9e4eef
    • Kan Liang's avatar
      perf script: Print source line for each jump in brstackinsn · 112c5547
      Kan Liang authored
      With the srcline option, the perf script only prints a source line at
      the beginning of a sample with call/ret from functions, but not for
      each jump in brstackinsn. It's useful to print a source line for each
      jump in brstackinsn when the end user analyze the full assembler
      sequences of branch sequences for the sample.
      
      The srccode option can also be used to locate the source code line.
      However, it's printed almost for every line and makes the output less
      readable.
      
       $perf script -F +brstackinsn,+srcline --xed
      
      Before the patch,
      
       tchain_edit_deb 1463275 15228549.107820:     282495 instructions:u:            401133 f3+0xd (/home/kan/os.li>
        tchain_edit.c:22
              f3+40:  tchain_edit.c:20
              000000000040114e                        jle 0x401133                    # PRED 6 cycles [6]
              0000000000401133                        movl  -0x4(%rbp), %eax
              0000000000401136                        and $0x1, %eax
              0000000000401139                        test %eax, %eax
              000000000040113b                        jz 0x401143
              000000000040113d                        addl  $0x1, -0x4(%rbp)
              0000000000401141                        jmp 0x401147                    # PRED 3 cycles [9] 2.00 IPC
              0000000000401147                        cmpl  $0x3e7, -0x4(%rbp)
              000000000040114e                        jle 0x401133                    # PRED 6 cycles [15] 0.33 IPC
      
      After the patch,
      
       tchain_edit_deb 1463275 15228549.107820:     282495 instructions:u:            401133 f3+0xd (/home/kan/os.li>
        tchain_edit.c:22
              f3+40:  tchain_edit.c:20
              000000000040114e                        jle 0x401133                     srcline: tchain_edit.c:20      # PRED 6 cycles [6]
              0000000000401133                        movl  -0x4(%rbp), %eax
              0000000000401136                        and $0x1, %eax
              0000000000401139                        test %eax, %eax
              000000000040113b                        jz 0x401143
              000000000040113d                        addl  $0x1, -0x4(%rbp)
              0000000000401141                        jmp 0x401147                     srcline: tchain_edit.c:23      # PRED 3 cycles [9] 2.00 IPC
              0000000000401147                        cmpl  $0x3e7, -0x4(%rbp)
              000000000040114e                        jle 0x401133                     srcline: tchain_edit.c:20      # PRED 6 cycles [15] 0.33 IPC
      Signed-off-by: default avatarKan Liang <kan.liang@linux.intel.com>
      Reviewed-by: default avatarIan Rogers <irogers@google.com>
      Cc: ahmad.yasin@intel.com
      Cc: amiri.khalil@intel.com
      Cc: ak@linux.intel.com
      Signed-off-by: default avatarNamhyung Kim <namhyung@kernel.org>
      Link: https://lore.kernel.org/r/20240205145819.1943114-1-kan.liang@linux.intel.com
      112c5547
    • Ian Rogers's avatar
      perf kvm powerpc: Fix build · 8ce5fa4d
      Ian Rogers authored
      Updates to struct parse_events_error needed to be carried through to
      PowerPC specific event parsing.
      
      Fixes: fd7b8e8f ("perf parse-events: Print all errors")
      Reported-by: default avatarStephen Rothwell <sfr@canb.auug.org.au>
      Signed-off-by: default avatarIan Rogers <irogers@google.com>
      Acked-by: default avatarNamhyung <namhyung@kernel.org>
      Cc: James Clark <james.clark@arm.com>
      Cc: Leo Yan <leo.yan@linaro.org>
      Cc: Kan Liang <kan.liang@linux.intel.com>
      Signed-off-by: default avatarNamhyung Kim <namhyung@kernel.org>
      Link: https://lore.kernel.org/r/20240206235902.2917395-1-irogers@google.com
      8ce5fa4d
  3. 06 Feb, 2024 1 commit
  4. 03 Feb, 2024 2 commits
  5. 02 Feb, 2024 9 commits
  6. 25 Jan, 2024 2 commits
  7. 24 Jan, 2024 10 commits
  8. 23 Jan, 2024 4 commits
  9. 22 Jan, 2024 8 commits
    • Yang Jihong's avatar
      perf data: Minor code style alignment cleanup · 57c8f107
      Yang Jihong authored
      Minor code style alignment cleanup for perf_data__switch() and
      perf_data__write().
      
      No functional change.
      Signed-off-by: default avatarYang Jihong <yangjihong1@huawei.com>
      Acked-by: default avatarNamhyung Kim <namhyung@kernel.org>
      Link: https://lore.kernel.org/r/20240119040304.3708522-4-yangjihong1@huawei.comSigned-off-by: default avatarNamhyung Kim <namhyung@kernel.org>
      57c8f107
    • Yang Jihong's avatar
      perf record: Check conflict between '--timestamp-filename' option and pipe mode before recording · 02f9b50e
      Yang Jihong authored
      In pipe mode, no need to switch perf data output, therefore,
      '--timestamp-filename' option should not take effect.
      Check the conflict before recording and output WARNING.
      In this case, the check pipe mode in perf_data__switch() can be removed.
      
      Before:
      
        # perf record --timestamp-filename -o- perf test -w noploop | perf report -i- --percent-limit=1
        # To display the perf.data header info, please use --header/--header-only options.
        #
        [ perf record: Woken up 1 times to write data ]
        [ perf record: Dump -.2024011812110182 ]
        #
        # Total Lost Samples: 0
        #
        # Samples: 4K of event 'cycles:P'
        # Event count (approx.): 2176784359
        #
        # Overhead  Command  Shared Object         Symbol
        # ........  .......  ....................  ......................................
        #
            97.83%  perf     perf                  [.] noploop
      
        #
        # (Tip: Print event counts in CSV format with: perf stat -x,)
        #
      
      After:
      
        # perf record --timestamp-filename -o- perf test -w noploop | perf report -i- --percent-limit=1
        WARNING: --timestamp-filename option is not available in pipe mode.
        # To display the perf.data header info, please use --header/--header-only options.
        #
        [ perf record: Woken up 1 times to write data ]
        [ perf record: Captured and wrote 0.000 MB - ]
        #
        # Total Lost Samples: 0
        #
        # Samples: 4K of event 'cycles:P'
        # Event count (approx.): 2185575421
        #
        # Overhead  Command  Shared Object          Symbol
        # ........  .......  .....................  .............................................
        #
            97.75%  perf     perf                   [.] noploop
      
        #
        # (Tip: Profiling branch (mis)predictions with: perf record -b / perf report)
        #
      
      Fixes: ecfd7a9c ("perf record: Add '--timestamp-filename' option to append timestamp to output file name")
      Signed-off-by: default avatarYang Jihong <yangjihong1@huawei.com>
      Acked-by: default avatarNamhyung Kim <namhyung@kernel.org>
      Link: https://lore.kernel.org/r/20240119040304.3708522-3-yangjihong1@huawei.comSigned-off-by: default avatarNamhyung Kim <namhyung@kernel.org>
      02f9b50e
    • Yang Jihong's avatar
      perf record: Fix possible incorrect free in record__switch_output() · aff10a16
      Yang Jihong authored
      perf_data__switch() may not assign a legal value to 'new_filename'.
      In this case, 'new_filename' uses the on-stack value, which may cause a
      incorrect free and unexpected result.
      
      Fixes: 03724b2e ("perf record: Allow to limit number of reported perf.data files")
      Signed-off-by: default avatarYang Jihong <yangjihong1@huawei.com>
      Acked-by: default avatarNamhyung Kim <namhyung@kernel.org>
      Link: https://lore.kernel.org/r/20240119040304.3708522-2-yangjihong1@huawei.comSigned-off-by: default avatarNamhyung Kim <namhyung@kernel.org>
      aff10a16
    • Namhyung Kim's avatar
      perf dwarf-aux: Check allowed DWARF Ops · 55442cc2
      Namhyung Kim authored
      The DWARF location expression can be fairly complex and it'd be hard
      to match it with the condition correctly.  So let's be conservative
      and only allow simple expressions.  For now it just checks the first
      operation in the list.  The following operations looks ok:
      
       * DW_OP_stack_value
       * DW_OP_deref_size
       * DW_OP_deref
       * DW_OP_piece
      
      To refuse complex (and unsupported) location expressions, add
      check_allowed_ops() to compare the rest of the list.  It seems earlier
      result contained those unsupported expressions.  For example, I found
      some local struct variable is placed like below.
      
       <2><43d1517>: Abbrev Number: 62 (DW_TAG_variable)
          <43d1518>   DW_AT_location    : 15 byte block: 91 50 93 8 91 78 93 4 93 84 8 91 68 93 4
              (DW_OP_fbreg: -48; DW_OP_piece: 8;
               DW_OP_fbreg: -8; DW_OP_piece: 4;
               DW_OP_piece: 1028;
               DW_OP_fbreg: -24; DW_OP_piece: 4)
      
      Another example is something like this.
      
          0057c8be ffffffffffffffff ffffffff812109f0 (base address)
          0057c8ce ffffffff812112b5 ffffffff812112c8 (DW_OP_breg3 (rbx): 0;
                                                      DW_OP_constu: 18446744073709551612;
                                                      DW_OP_and;
                                                      DW_OP_stack_value)
      
      It should refuse them.  After the change, the stat shows:
      
        Annotate data type stats:
        total 294, ok 158 (53.7%), bad 136 (46.3%)
        -----------------------------------------------------------
                30 : no_sym
                32 : no_mem_ops
                53 : no_var
                14 : no_typeinfo
                 7 : bad_offset
      Acked-by: default avatarMasami Hiramatsu (Google) <mhiramat@kernel.org>
      Reviewed-by: default avatarIan Rogers <irogers@google.com>
      Cc: Stephane Eranian <eranian@google.com>
      Link: https://lore.kernel.org/r/20240117062657.985479-10-namhyung@kernel.orgSigned-off-by: default avatarNamhyung Kim <namhyung@kernel.org>
      55442cc2
    • Namhyung Kim's avatar
      perf annotate-data: Support stack variables · bc10db8e
      Namhyung Kim authored
      Local variables are allocated in the stack and the location list
      should look like base register(s) and an offset.  Extend the
      die_find_variable_by_reg() to handle the following expressions
      
       * DW_OP_breg{0..31}
       * DW_OP_bregx
       * DW_OP_fbreg
      
      Ususally DWARF subprogram entries have frame base information and
      use it to locate stack variable like below:
      
       <2><43d1575>: Abbrev Number: 62 (DW_TAG_variable)
          <43d1576>   DW_AT_location    : 2 byte block: 91 7c         (DW_OP_fbreg: -4)  <--- here
          <43d1579>   DW_AT_name        : (indirect string, offset: 0x2c00c9): i
          <43d157d>   DW_AT_decl_file   : 1
          <43d157e>   DW_AT_decl_line   : 78
          <43d157f>   DW_AT_type        : <0x43d19d7>
      
      I found some differences on saving the frame base between gcc and clang.
      The gcc uses the CFA to get the base so it needs to check the current
      frame's CFI info.  In this case, stack offset needs to be adjusted from
      the start of the CFA.
      
       <1><1bb8d>: Abbrev Number: 102 (DW_TAG_subprogram)
          <1bb8e>   DW_AT_name        : (indirect string, offset: 0x74d41): kernel_init
          <1bb92>   DW_AT_decl_file   : 2
          <1bb92>   DW_AT_decl_line   : 1440
          <1bb94>   DW_AT_decl_column : 18
          <1bb95>   DW_AT_prototyped  : 1
          <1bb95>   DW_AT_type        : <0xcc>
          <1bb99>   DW_AT_low_pc      : 0xffffffff81bab9e0
          <1bba1>   DW_AT_high_pc     : 0x1b2
          <1bba9>   DW_AT_frame_base  : 1 byte block: 9c      (DW_OP_call_frame_cfa)  <------ here
          <1bbab>   DW_AT_call_all_calls: 1
          <1bbab>   DW_AT_sibling     : <0x1bf5a>
      
      While clang sets it to a register directly and it can check the register
      and offset in the instruction directly.
      
       <1><43d1542>: Abbrev Number: 60 (DW_TAG_subprogram)
          <43d1543>   DW_AT_low_pc      : 0xffffffff816a7c60
          <43d154b>   DW_AT_high_pc     : 0x98
          <43d154f>   DW_AT_frame_base  : 1 byte block: 56    (DW_OP_reg6 (rbp))  <---------- here
          <43d1551>   DW_AT_GNU_all_call_sites: 1
          <43d1551>   DW_AT_name        : (indirect string, offset: 0x3bce91): foo
          <43d1555>   DW_AT_decl_file   : 1
          <43d1556>   DW_AT_decl_line   : 75
          <43d1557>   DW_AT_prototyped  : 1
          <43d1557>   DW_AT_type        : <0x43c7332>
          <43d155b>   DW_AT_external    : 1
      
      Also it needs to update the offset after finding the type like global
      variables since the offset was from the frame base.  Factor out
      match_var_offset() to check global and local variables in the same way.
      
      The type stats are improved too:
      
        Annotate data type stats:
        total 294, ok 160 (54.4%), bad 134 (45.6%)
        -----------------------------------------------------------
                30 : no_sym
                32 : no_mem_ops
                51 : no_var
                14 : no_typeinfo
                 7 : bad_offset
      Reviewed-by: default avatarIan Rogers <irogers@google.com>
      Cc: Stephane Eranian <eranian@google.com>
      Cc: Masami Hiramatsu <mhiramat@kernel.org>
      Link: https://lore.kernel.org/r/20240117062657.985479-9-namhyung@kernel.orgSigned-off-by: default avatarNamhyung Kim <namhyung@kernel.org>
      bc10db8e
    • Namhyung Kim's avatar
      perf dwarf-aux: Add die_get_cfa() · 6fed025f
      Namhyung Kim authored
      The die_get_cfa() is to get frame base register and offset at the given
      instruction address (pc).  This info will be used to locate stack
      variables which have location expression using DW_OP_fbreg.
      Reviewed-by: default avatarIan Rogers <irogers@google.com>
      Cc: Stephane Eranian <eranian@google.com>
      Cc: Masami Hiramatsu <mhiramat@kernel.org>
      Link: https://lore.kernel.org/r/20240117062657.985479-8-namhyung@kernel.orgSigned-off-by: default avatarNamhyung Kim <namhyung@kernel.org>
      6fed025f
    • Namhyung Kim's avatar
      perf annotate-data: Support global variables · 5f7cdde8
      Namhyung Kim authored
      Global variables are accessed using PC-relative address so it needs to
      be handled separately.  The PC-rel addressing is detected by using
      DWARF_REG_PC.  On x86, %rip register would be used.
      
      The address can be calculated using the ip and offset in the
      instruction.  But it should start from the next instruction so add
      calculate_pcrel_addr() to do it properly.
      
      But global variables defined in a different file would only have a
      declaration which doesn't include a location list.  So it first tries
      to get the type info using the address, and then looks up the variable
      declarations using name.  The name of global variables should be get
      from the symbol table.  The declaration would have the type info.
      
      So extend find_var_type() to take both address and name for global
      variables.
      
      The stat is now looks like:
      
        Annotate data type stats:
        total 294, ok 153 (52.0%), bad 141 (48.0%)
        -----------------------------------------------------------
                30 : no_sym
                32 : no_mem_ops
                61 : no_var
                10 : no_typeinfo
                 8 : bad_offset
      Reviewed-by: default avatarIan Rogers <irogers@google.com>
      Cc: Stephane Eranian <eranian@google.com>
      Cc: Masami Hiramatsu <mhiramat@kernel.org>
      Link: https://lore.kernel.org/r/20240117062657.985479-7-namhyung@kernel.orgSigned-off-by: default avatarNamhyung Kim <namhyung@kernel.org>
      5f7cdde8
    • Namhyung Kim's avatar
      perf annotate-data: Handle PC-relative addressing · 83bfa06d
      Namhyung Kim authored
      Extend find_data_type_die() to find data type from PC-relative address
      using die_find_variable_by_addr().  Users need to pass the address for
      the (global) variable.
      
      The offset for the variable should be updated after finding the type
      because the offset in the instruction is just to calcuate the address
      for the variable.  So it changed to pass a pointer to offset and renamed
      it to 'poffset'.
      
      First it searches variables in the CU DIE as it's likely that the global
      variables are defined in the file level.  And then it iterates the scope
      DIEs to find a local (static) variable.
      Reviewed-by: default avatarIan Rogers <irogers@google.com>
      Cc: Stephane Eranian <eranian@google.com>
      Cc: Masami Hiramatsu <mhiramat@kernel.org>
      Link: https://lore.kernel.org/r/20240117062657.985479-6-namhyung@kernel.orgSigned-off-by: default avatarNamhyung Kim <namhyung@kernel.org>
      83bfa06d