1. 09 5月, 2015 4 次提交
    • M
      perf probe: Support glob wildcards for function name · 4c859351
      Masami Hiramatsu 提交于
      Support glob wildcards for function name when adding new probes. This
      will allow us to build caches of function-entry level information with
      $params.
      
      e.g.
        ----
        # perf probe --no-inlines --add 'kmalloc* $params'
        Added new events:
          probe:kmalloc_slab   (on kmalloc* with $params)
          probe:kmalloc_large_node (on kmalloc* with $params)
          probe:kmalloc_order_trace (on kmalloc* with $params)
      
        You can now use it in all perf tools, such as:
      
              perf record -e probe:kmalloc_order_trace -aR sleep 1
      
        # perf probe --list
          probe:kmalloc_large_node (on kmalloc_large_node@mm/slub.c with size flags node)
          probe:kmalloc_order_trace (on kmalloc_order_trace@mm/slub.c with size flags order)
          probe:kmalloc_slab   (on kmalloc_slab@mm/slab_common.c with size flags)
        ----
      Signed-off-by: NMasami Hiramatsu <masami.hiramatsu.pt@hitachi.com>
      Tested-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      Cc: Ananth N Mavinakayanahalli <ananth@in.ibm.com>
      Cc: David Ahern <dsahern@gmail.com>
      Cc: Hemant Kumar <hemant@linux.vnet.ibm.com>
      Cc: Jiri Olsa <jolsa@redhat.com>
      Cc: Namhyung Kim <namhyung@kernel.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Link: http://lkml.kernel.org/r/20150508010335.24812.19972.stgit@localhost.localdomainSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      4c859351
    • M
      perf probe: Add --no-inlines option to avoid searching inline functions · 6cfd1f68
      Masami Hiramatsu 提交于
      Add --no-inlines(--inlines) option to avoid searching inline functions.
      
      Searching all functions which matches glob pattern can take a long time
      and find a lot of inline functions.
      
      With this option perf-probe searches target on the non-inlined
      functions.
      Signed-off-by: NMasami Hiramatsu <masami.hiramatsu.pt@hitachi.com>
      Cc: Ananth N Mavinakayanahalli <ananth@in.ibm.com>
      Cc: David Ahern <dsahern@gmail.com>
      Cc: Hemant Kumar <hemant@linux.vnet.ibm.com>
      Cc: Jiri Olsa <jolsa@redhat.com>
      Cc: Namhyung Kim <namhyung@kernel.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Link: http://lkml.kernel.org/r/20150508010333.24812.86568.stgit@localhost.localdomainSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      6cfd1f68
    • M
      perf probe: Introduce probe_conf global configs · ddb2f58f
      Masami Hiramatsu 提交于
      Introduce probe_conf global configuration parameters for probe-event and
      probe-finder, and removes related parameters from APIs.
      Signed-off-by: NMasami Hiramatsu <masami.hiramatsu.pt@hitachi.com>
      Cc: Ananth N Mavinakayanahalli <ananth@in.ibm.com>
      Cc: David Ahern <dsahern@gmail.com>
      Cc: Hemant Kumar <hemant@linux.vnet.ibm.com>
      Cc: Jiri Olsa <jolsa@redhat.com>
      Cc: Namhyung Kim <namhyung@kernel.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Link: http://lkml.kernel.org/r/20150508010330.24812.21095.stgit@localhost.localdomainSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      ddb2f58f
    • M
      perf probe: Support $params special probe argument · f8bffbf1
      Masami Hiramatsu 提交于
      $params is similar to $vars but matches only function parameters not
      local variables.
      
      Thus, this is useful for tracing function parameter changing or tracing
      function call with parameters.
      
      Testing it:
      
       # perf probe tcp_sendmsg '$params'
       Added new event:
        probe:tcp_sendmsg    (on tcp_sendmsg with $params)
      
       You can now use it in all perf tools, such as:
      
      	perf record -e probe:tcp_sendmsg -aR sleep 1
      
       # perf probe -l
        probe:tcp_sendmsg    (on tcp_sendmsg@acme/git/linux/net/ipv4/tcp.c with iocb sk msg size)
       # perf record -a -e probe:*
       press some random letters to generate TCP (sshd) traffic...
      
       ^C[ perf record: Woken up 1 times to write data ]
       [ perf record: Captured and wrote 0.223 MB perf.data (6 samples) ]
      
       # perf script
         sshd 6385 [2] 3.907529: probe:tcp_sendmsg: iocb=0xffff8800ac4cfe70 sk=0xffff88042196c140 msg=0xffff8800ac4cfda8 size=0x24
         sshd 6385 [2] 4.138973: probe:tcp_sendmsg: iocb=0xffff8800ac4cfe70 sk=0xffff88042196c140 msg=0xffff8800ac4cfda8 size=0x24
         sshd 6385 [2] 4.378966: probe:tcp_sendmsg: iocb=0xffff8800ac4cfe70 sk=0xffff88042196c140 msg=0xffff8800ac4cfda8 size=0x24
         sshd 6385 [2] 4.603681: probe:tcp_sendmsg: iocb=0xffff8800ac4cfe70 sk=0xffff88042196c140 msg=0xffff8800ac4cfda8 size=0x24
         sshd 6385 [2] 4.818455: probe:tcp_sendmsg: iocb=0xffff8800ac4cfe70 sk=0xffff88042196c140 msg=0xffff8800ac4cfda8 size=0x24
         sshd 6385 [2] 5.043603: probe:tcp_sendmsg: iocb=0xffff8800ac4cfe70 sk=0xffff88042196c140 msg=0xffff8800ac4cfda8 size=0x24
       # cat /sys/kernel/debug/tracing/events/probe/tcp_sendmsg/format
       name: tcp_sendmsg
       ID: 1927
       format:
         field:unsigned short common_type;	offset:0;	size:2;	signed:0;
         field:unsigned char common_flags;	offset:2;	size:1;	signed:0;
         field:unsigned char common_preempt_count;	offset:3;	size:1;	signed:0;
         field:int common_pid;	offset:4;	size:4;	signed:1;
      
         field:unsigned long __probe_ip;	offset:8;	size:8;	signed:0;
         field:u64 iocb;	offset:16;	size:8;	signed:0;
         field:u64 sk;	offset:24;	size:8;	signed:0;
         field:u64 msg;	offset:32;	size:8;	signed:0;
         field:u64 size;	offset:40;	size:8;	signed:0;
      
       print fmt: "(%lx) iocb=0x%Lx sk=0x%Lx msg=0x%Lx size=0x%Lx", REC->__probe_ip, REC->iocb, REC->sk, REC->msg, REC->size
       #
      
       Do some system wide tracing of this probe + write syscalls:
      
       # perf trace -e write --ev probe:* --filter-pids 6385
        462.612 (0.010 ms): bash/19153 write(fd: 1</dev/pts/1>, buf: 0x7f7556c78000, count: 29               ) = 29
        462.701 (0.027 ms): sshd/19152 write(fd: 3<socket:[63117]>, buf: 0x7f78dd12e160, count: 68           ) ...
        462.701 (        ): probe:tcp_sendmsg:(ffffffff8163db30) iocb=0xffff8803ebec7e70 sk=0xffff88042196ab80 msg=0xffff8803ebec7da8 size=0x44)
        462.710 (0.035 ms): sshd/19152  ... [continued]: write()) = 68
        462.787 (0.009 ms): bash/19153 write(fd: 2</dev/pts/1>, buf: 0x7f7556c77000, count: 22               ) = 22
        462.865 (0.002 ms): sshd/19152 write(fd: 3<socket:[63117]>, buf: 0x7f78dd12e160, count: 68           ) ...
        462.865 (        ): probe:tcp_sendmsg:(ffffffff8163db30) iocb=0xffff8803ebec7e70 sk=0xffff88042196ab80 msg=0xffff8803ebec7da8 size=0x44)
        462.873 (0.010 ms): sshd/19152  ... [continued]: write()) = 68
      Signed-off-by: NMasami Hiramatsu <masami.hiramatsu.pt@hitachi.com>
      Tested-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      Cc: Ananth N Mavinakayanahalli <ananth@in.ibm.com>
      Cc: David Ahern <dsahern@gmail.com>
      Cc: Hemant Kumar <hemant@linux.vnet.ibm.com>
      Cc: Jiri Olsa <jolsa@redhat.com>
      Cc: Namhyung Kim <namhyung@kernel.org>
      Cc: Peter Zijlstra <peterz@infradead.org>
      Link: http://lkml.kernel.org/r/20150506124653.4961.59806.stgit@localhost.localdomain
      [ Add some examples to the changelog message showing how to use it ]
      Signed-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      f8bffbf1
  2. 28 4月, 2015 1 次提交
    • H
      perf probe: Fix bug with global variables handling · d13855ef
      He Kuang 提交于
      There are missing curly braces which causes find_variable() return wrong
      value when probing with global variables.
      
      This problem can be reproduced as following:
      
        $ perf probe -v --add='generic_perform_write global_variable_for_test'
        ...
        Try to find probe point from debuginfo.
        Probe point found: generic_perform_write+0
        Searching 'global_variable_for_test' variable in context.
        An error occurred in debuginfo analysis (-2).
          Error: Failed to add events. Reason: No such file or directory (Code: -2)
      
      After this patch:
      
        $ perf probe -v --add='generic_perform_write global_variable_for_test'
        ...
        Converting variable global_variable_for_test into trace event.
        global_variable_for_test type is int.
        Found 1 probe_trace_events.
        Opening /sys/kernel/debug/tracing/kprobe_events write=1
        Added new event:
        Writing event: p:probe/generic_perform_write _stext+1237464
        global_variable_for_test=@global_variable_for_test+0:s32
          probe:generic_perform_write (on generic_perform_write with
          global_variable_for_test)
      
        You can now use it in all perf tools, such as:
      
            perf record -e probe:generic_perform_write -aR sleep 1
      Signed-off-by: NHe Kuang <hekuang@huawei.com>
      Acked-by: NMasami Hiramatsu <masami.hiramatsu.pt@hitachi.com>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
      Cc: Wang Nan <wangnan0@huawei.com>
      Link: http://lkml.kernel.org/r/1429949338-18678-1-git-send-email-hekuang@huawei.comSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      d13855ef
  3. 14 4月, 2015 2 次提交
  4. 03 4月, 2015 1 次提交
  5. 07 3月, 2015 1 次提交
  6. 02 3月, 2015 1 次提交
  7. 06 2月, 2015 1 次提交
  8. 02 1月, 2015 1 次提交
    • N
      perf probe: Fix crash in dwarf_getcfi_elf · 4093325f
      Namhyung Kim 提交于
      David reported that perf can segfault when adding an uprobe event like
      this:
      
        $ perf probe -x /lib64/libc-2.14.90.so -a 'malloc  size=%di'
      
        (gdb) bt
        #0  parse_eh_frame_hdr (hdr=0x0, hdr_size=2596, hdr_vaddr=71788,
            ehdr=0x7fffffffd390, eh_frame_vaddr=
            0x7fffffffd378, table_entries=0x8808d8, table_encoding=0x8808e0 "") at
            dwarf_getcfi_elf.c:79
        #1  0x000000385f81615a in getcfi_scn_eh_frame (hdr_vaddr=71788,
            hdr_scn=0x8839b0, shdr=0x7fffffffd2f0, scn=<optimized out>,
            ehdr=0x7fffffffd390, elf=0x882b30) at dwarf_getcfi_elf.c:231
        #2  getcfi_shdr (ehdr=0x7fffffffd390, elf=0x882b30) at dwarf_getcfi_elf.c:283
        #3  dwarf_getcfi_elf (elf=0x882b30) at dwarf_getcfi_elf.c:309
        #4  0x00000000004d5bac in debuginfo__find_probes (pf=0x7fffffffd4f0,
            dbg=Unhandled dwarf expression opcode 0xfa) at util/probe-finder.c:993
        #5  0x00000000004d634a in debuginfo__find_trace_events (dbg=0x880840,
            pev=<optimized out>, tevs=0x880f88, max_tevs=<optimized out>) at
            util/probe-finder.c:1200
        #6  0x00000000004aed6b in try_to_find_probe_trace_events (target=0x881b20
            "/lib64/libpthread-2.14.90.so",
            max_tevs=128, tevs=0x880f88, pev=0x859b30) at util/probe-event.c:482
        #7  convert_to_probe_trace_events (target=0x881b20
            "/lib64/libpthread-2.14.90.so", max_tevs=128, tevs=0x880f88,
            pev=0x859b30) at util/probe-event.c:2356
        #8  add_perf_probe_events (pevs=<optimized out>, npevs=1, max_tevs=128,
            target=0x881b20 "/lib64/libpthread-2.14.90.so", force_add=false) at
            util/probe-event.c:2391
        #9  0x000000000044014f in __cmd_probe (argc=<optimized out>,
            argv=0x7fffffffe2f0, prefix=Unhandled dwarf expression opcode 0xfa) at
            at builtin-probe.c:488
        #10 0x0000000000440313 in cmd_probe (argc=5, argv=0x7fffffffe2f0,
            prefix=<optimized out>) at builtin-probe.c:506
        #11 0x000000000041d133 in run_builtin (p=0x805680, argc=5,
            argv=0x7fffffffe2f0) at perf.c:341
        #12 0x000000000041c8b2 in handle_internal_command (argv=<optimized out>,
            argc=<optimized out>) at perf.c:400
        #13 run_argv (argv=<optimized out>, argcp=<optimized out>) at perf.c:444
        #14 main (argc=5, argv=0x7fffffffe2f0) at perf.c:559
      
      And I found a related commit (5704c8c4fa71 "getcfi_scn_eh_frame: Don't
      crash and burn when .eh_frame bits aren't there.") in elfutils that can
      lead to a unexpected crash like this.  To safely use the function, it
      needs to check the .eh_frame section is a PROGBITS type.
      Reported-by: NDavid Ahern <dsahern@gmail.com>
      Tested-by: NDavid Ahern <dsahern@gmail.com>
      Signed-off-by: NNamhyung Kim <namhyung@kernel.org>
      Acked-by: NMasami Hiramatsu <masami.hiramatsu.pt@hitachi.com>
      Cc: David Ahern <dsahern@gmail.com>
      Cc: Mark Wielaard <mjw@redhat.com>
      Cc: Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com>
      Link: http://lkml.kernel.org/r/20141230090533.GH6081@sejongSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      4093325f
  9. 18 9月, 2014 1 次提交
  10. 15 8月, 2014 1 次提交
  11. 17 7月, 2014 1 次提交
  12. 10 6月, 2014 1 次提交
    • M
      perf probe: Improve an error message of perf probe --vars mode · 69e96eaa
      Masami Hiramatsu 提交于
      Fix an error message when failed to find given address in --vars
      mode.
      
      Without this fix, perf probe -V doesn't show the final "Error"
      message if it fails to find given source line. Moreover, it
      tells it fails to find "variables" instead of the source line.
        -----
        # perf probe -V foo@bar
        Failed to find variables at foo@bar (0)
        -----
      The result also shows mysterious error code. Actually the error
      returns 0 or -ENOENT means that it just fails to find the address
      of given source line. (0 means there is no matching address,
      and -ENOENT means there is an entry(DIE) but it has no instance,
      e.g. an empty inlined function)
      
      This fixes it to show what happened and the final error message
      as below.
        -----
        # perf probe -V foo@bar
        Failed to find the address of foo@bar
          Error: Failed to show vars.
        -----
      Signed-off-by: NMasami Hiramatsu <masami.hiramatsu.pt@hitachi.com>
      Cc: Ingo Molnar <mingo@kernel.org>
      Cc: Jiri Olsa <jolsa@redhat.com>
      Cc: Namhyung Kim <namhyung@kernel.org>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
      Link: http://lkml.kernel.org/r/20140606071359.6788.84716.stgit@kbuild-fedora.novalocalSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      69e96eaa
  13. 09 6月, 2014 1 次提交
  14. 04 6月, 2014 1 次提交
  15. 14 4月, 2014 3 次提交
  16. 18 2月, 2014 3 次提交
  17. 28 12月, 2013 2 次提交
  18. 27 12月, 2013 1 次提交
  19. 26 12月, 2013 1 次提交
    • M
      perf probe: Support basic dwarf-based operations on uprobe events · fb7345bb
      Masami Hiramatsu 提交于
      Support basic dwarf(debuginfo) based operations for uprobe events.  With
      this change, perf probe can analyze debuginfo of user application binary
      to set up new uprobe event.
      
      This allows perf-probe --add(with local variables, line numbers) and
      --line works with -x option.  (Actually, --vars has already accepted -x
      option)
      
      For example, the following command shows the probe-able lines of a given
      user space function. Something that so far was only available in the
      'perf probe' tool for kernel space functions:
      
        # ./perf probe -x perf --line map__load
        <map__load@/home/fedora/ksrc/linux-2.6/tools/perf/util/map.c:0>
              0  int map__load(struct map *map, symbol_filter_t filter)
              1  {
              2         const char *name = map->dso->long_name;
                        int nr;
      
              5         if (dso__loaded(map->dso, map->type))
              6                 return 0;
      
              8         nr = dso__load(map->dso, map, filter);
              9         if (nr < 0) {
             10                 if (map->dso->has_build_id) {
      
      And this shows the available variables at the given line of the
      function.
      
        # ./perf probe -x perf --vars map__load:8
        Available variables at map__load:8
                @<map__load+96>
                        char*   name
                        struct map*     map
                        symbol_filter_t filter
                @<map__find_symbol+112>
                        char*   name
                        symbol_filter_t filter
                @<map__find_symbol_by_name+136>
                        char*   name
                        symbol_filter_t filter
                @<map_groups__find_symbol_by_name+176>
                        char*   name
                        struct map*     map
                        symbol_filter_t filter
      
      And lastly, we can now define probe(s) with all available
      variables on the given line:
      
        # ./perf probe -x perf --add 'map__load:8 $vars'
      
        Added new events:
          probe_perf:map__load (on map__load:8 with $vars)
          probe_perf:map__load_1 (on map__load:8 with $vars)
          probe_perf:map__load_2 (on map__load:8 with $vars)
          probe_perf:map__load_3 (on map__load:8 with $vars)
      
        You can now use it in all perf tools, such as:
      
                perf record -e probe_perf:map__load_3 -aR sleep 1
      
        Changes from previous version:
         - Add examples in the patch description.
         - Use .text section start address and dwarf symbol address
           for calculating the offset of given symbol, instead of
           searching the symbol in symtab again.
           With this change, we can safely handle multiple local
           function instances (e.g. scnprintf in perf).
      Signed-off-by: NMasami Hiramatsu <masami.hiramatsu.pt@hitachi.com>
      Cc: David Ahern <dsahern@gmail.com>
      Cc: David A. Long <dave.long@linaro.org>
      Cc: Ingo Molnar <mingo@kernel.org>
      Cc: Namhyung Kim <namhyung@kernel.org>
      Cc: Oleg Nesterov <oleg@redhat.com>
      Cc: Srikar Dronamraju <srikar@linux.vnet.ibm.com>
      Cc: Steven Rostedt <rostedt@goodmis.org>
      Cc: systemtap@sourceware.org
      Cc: yrl.pp-manager.tt@hitachi.com
      Link: http://lkml.kernel.org/r/20131226054152.22364.47021.stgit@kbuild-fedora.novalocalSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      fb7345bb
  20. 06 11月, 2013 1 次提交
  21. 04 11月, 2013 1 次提交
  22. 23 10月, 2013 2 次提交
  23. 16 10月, 2013 1 次提交
  24. 05 10月, 2013 1 次提交
    • M
      perf probe: Fix to find line information for probe list · e08cfd4b
      Masami Hiramatsu 提交于
      Fix to find the correct (as much as possible) line information for
      listing probes. Without this fix, perf probe --list action will show
      incorrect line information as below;
      
        probe:getname_flags  (on getname_flags@ksrc/linux-3/fs/namei.c)
        probe:getname_flags_1 (on getname:-89@x86/include/asm/current.h)
        probe:getname_flags_2 (on user_path_at_empty:-2054@x86/include/asm/current.h)
      
      The minus line number is obviously wrong, and current.h is not related
      to the probe point. Deeper investigation discovered that there were 2
      issues related to this bug, and minor typos too.
      
      The 1st issue is the rack of considering about nested inlined functions,
      which causes the wrong (relative) line number.
      
      The 2nd issue is that the dwarf line info is not correct at those
      points. It points 14th line of current.h.
      
      Since it seems that the line info includes somewhat unreliable
      information, this fixes perf to try to find correct line information
      from both of debuginfo and line info as below.
      
      1) Probe address is the entry of a function instance
      
        In this case, the line is set as the function declared line.
      
      2) Probe address is the entry of an expanded inline function block
      
        In this case, the line is set as the function call-site line.
        This means that the line number is relative from the entry line
        of caller function (which can be an inlined function if nested)
      
      3) Probe address is inside a function instance or an expanded
         inline function block
      
        In this case, perf probe queries the line number from lineinfo
        and verify the function declared file is same as the file name
        queried from lineinfo.
      
        If the file name is different, it is a failure case. The probe
        address is shown as symbol+offset.
      
      4) Probe address is not in the any function instance
      
        This is a failure case, the probe address is shown as
        symbol+offset.
      
      With this fix, perf probe -l shows correct probe lines as below;
      
        probe:getname_flags  (on getname_flags@ksrc/linux-3/fs/namei.c)
        probe:getname_flags_1 (on getname:2@ksrc/linux-3/fs/namei.c)
        probe:getname_flags_2 (on user_path_at_empty:4@ksrc/linux-3/fs/namei.c)
      
      Changes at v2:
       - Fix typos in the function comments. (Thanks to Namhyung Kim)
       - Use die_find_top_inlinefunc instead of die_find_inlinefunc_next.
      Signed-off-by: NMasami Hiramatsu <masami.hiramatsu.pt@hitachi.com>
      Cc: Ingo Molnar <mingo@redhat.com>
      Cc: Namhyung Kim <namhyung@kernel.org>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
      Link: http://lkml.kernel.org/r/20130930092144.1693.11058.stgit@udc4-manage.rcp.hitachi.co.jpSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      e08cfd4b
  25. 25 9月, 2013 1 次提交
    • M
      perf probe: Fix probing symbols with optimization suffix · 576b5237
      Masami Hiramatsu 提交于
      Fix perf probe to probe on some symbols which have some optimzation
      suffixes, e.g. ".part", ".isra", and ".constprop".
      
      To fix this issue, instead of using the DIE name, perf probe uses the
      symbol name found by dwfl_module_addrsym().
      
      This also involves a perf probe --vars operation update which now shows
      the symbol name instead of the DIE name.
      
      Without this patch, putting a probe on an inlined function which was
      compiled with a suffixed symbol will fail like this:
      
        $ perf probe -v getname_flags
        probe-definition(0): getname_flags
        symbol:getname_flags file:(null) line:0 offset:0 return:0 lazy:(null)
        0 arguments
        Looking at the vmlinux_path (6 entries long)
        Using /lib/modules/3.11.0+/build/vmlinux for symbols
        found inline addr: 0xffffffff8119bb70
        Probe point found: getname_flags+0
        found inline addr: 0xffffffff8119bcb6
        Probe point found: getname+6
        found inline addr: 0xffffffff811a06a6
        Probe point found: user_path_at_empty+6
        find 3 probe_trace_events.
        Opening /sys/kernel/debug//tracing/kprobe_events write=1
        Added new events:
        Writing event: p:probe/getname_flags getname_flags+0
        Failed to write event: No such file or directory
          Error: Failed to add events. (-1)
      
      Because the debuginfo knows only the original (non suffix) symbol name,
      it uses the original symbol for probe address but the kernel (kallsyms)
      knows only suffixed symbol.  Then, the kernel rejects that original
      symbol.
      
      This patch uses dwfl_module_addrsym() to get the correct (suffixed)
      symbol from symtab when a probe point is found.
      Reported-by: NArnaldo Carvalho de Melo <acme@ghostprotocols.net>
      Signed-off-by: NMasami Hiramatsu <masami.hiramatsu.pt@hitachi.com>
      Cc: Ingo Molnar <mingo@redhat.com>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
      Link: http://lkml.kernel.org/r/20130925131616.31632.46658.stgit@udc4-manage.rcp.hitachi.co.jpSigned-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      576b5237
  26. 19 9月, 2013 1 次提交
  27. 25 1月, 2013 1 次提交
  28. 15 9月, 2012 1 次提交
  29. 11 9月, 2012 1 次提交
    • I
      perf tools: Use __maybe_used for unused variables · 1d037ca1
      Irina Tirdea 提交于
      perf defines both __used and __unused variables to use for marking
      unused variables. The variable __used is defined to
      __attribute__((__unused__)), which contradicts the kernel definition to
      __attribute__((__used__)) for new gcc versions. On Android, __used is
      also defined in system headers and this leads to warnings like: warning:
      '__used__' attribute ignored
      
      __unused is not defined in the kernel and is not a standard definition.
      If __unused is included everywhere instead of __used, this leads to
      conflicts with glibc headers, since glibc has a variables with this name
      in its headers.
      
      The best approach is to use __maybe_unused, the definition used in the
      kernel for __attribute__((unused)). In this way there is only one
      definition in perf sources (instead of 2 definitions that point to the
      same thing: __used and __unused) and it works on both Linux and Android.
      This patch simply replaces all instances of __used and __unused with
      __maybe_unused.
      Signed-off-by: NIrina Tirdea <irina.tirdea@intel.com>
      Acked-by: NPekka Enberg <penberg@kernel.org>
      Cc: David Ahern <dsahern@gmail.com>
      Cc: Ingo Molnar <mingo@redhat.com>
      Cc: Namhyung Kim <namhyung.kim@lge.com>
      Cc: Paul Mackerras <paulus@samba.org>
      Cc: Peter Zijlstra <a.p.zijlstra@chello.nl>
      Cc: Steven Rostedt <rostedt@goodmis.org>
      Link: http://lkml.kernel.org/r/1347315303-29906-7-git-send-email-irina.tirdea@intel.com
      [ committer note: fixed up conflict with a116e05d in builtin-sched.c ]
      Signed-off-by: NArnaldo Carvalho de Melo <acme@redhat.com>
      1d037ca1
  30. 28 3月, 2012 1 次提交