All of lore.kernel.org
 help / color / mirror / Atom feed
From: David Ahern <dsahern@gmail.com>
To: Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com>
Cc: acme@ghostprotocols.net, linux-kernel@vger.kernel.org,
	Srikar Dronamraju <srikar@linux.vnet.ibm.com>,
	Oleg Nesterov <oleg@redhat.com>,
	namhyung@kernel.org,
	"yrl.pp-manager.tt@hitachi.com" <yrl.pp-manager.tt@hitachi.com>
Subject: Re: [PATCH 2/2] perf probe: Allow user to specify address within executable
Date: Mon, 02 Dec 2013 10:55:06 -0700	[thread overview]
Message-ID: <529CC97A.6000807@gmail.com> (raw)
In-Reply-To: <529C9DDF.1080401@gmail.com>

On 12/2/13, 7:49 AM, David Ahern wrote:
> On 12/1/13, 11:15 PM, Masami Hiramatsu wrote:
>> (2013/12/02 9:07), David Ahern wrote:
>>> Allow user to specify an address within an executable. This is useful, for
>>> example, in probing local functions. If the function name begins with 0x
>>> then try to convert the supplied name to an address. If succuessful then
>>> treat the function name as the address within the executable to be probed.
>>
>> Hmm, IMHO, this kind of functionality is only good for debugging.
> 
> Why? perf-probe takes the function name, looks up the address in the
> executable, adds an offset and then pushes that address to the kernel.
> Why can't I have an option to jump straight to the desired address?
> 
> A few use cases that come to mind:
> 
> 1. Allows manual creation of return probes in kernels which do not have
> that support.
> 
> 2. probing static functions

D'oh. That is supposed to be local functions, not static functions.
Right now perf-probe does not allow probes in local functions of an
executable. Giving a specific address provides a mean to do that.

> 
> 3. probing versioned addresses in libc -- something the current syntax
> does not allow because '@' is used as a field separator:
> 
> $ nm /lib64/libc-2.14.90.so | grep pthread_cond_timedwait
> 00000000000fe6c0 t __pthread_cond_timedwait
> 000000000012d920 t __pthread_cond_timedwait_2_0
> 00000000000fe6c0 T pthread_cond_timedwait@@GLIBC_2.3.2
> 000000000012d920 T pthread_cond_timedwait@GLIBC_2.2.5
> 
> $ perf probe -x /lib64/libc-2.14.90.so -a
> 'cond_timewait=pthread_cond_timedwait'
> no symbols found in /lib64/libc-2.14.90.so, maybe install a debug package?
> Failed to load map.
>    Error: Failed to add events. (-22)
> 
> $ perf probe -x /lib64/libc-2.14.90.so -a
> 'cond_timewait=pthread_cond_timedwait@@GLIBC_2.3.2'
> Semantic error :SRC@SRC is not allowed.
> 
> 
> 4. A workaround for any other shortcomings in the interface that require
> patches to fix and backports to be done. backports which take time if
> even possible.
> 
>> In that case, you should use uprobe_events interface directly.
> 
> How do I do that within the context of perf?
> 
>>
>> I recommend you to try enabing dwarf support in user space.
>> Perf probe is a user-friendly interface of dynamic events.
> 
> I do have dwarf support enabled in perf. Are you referring to other
> components of userspace (like system libraries)?
> 
> David
> 


  reply	other threads:[~2013-12-02 17:55 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-12-02  0:07 [PATCH 1/2] perf probe: Improve error message when function not found David Ahern
2013-12-02  0:07 ` [PATCH 2/2] perf probe: Allow user to specify address within executable David Ahern
2013-12-02  5:53   ` Masami Hiramatsu
2013-12-02  6:15   ` Masami Hiramatsu
2013-12-02 14:49     ` David Ahern
2013-12-02 17:55       ` David Ahern [this message]
2013-12-03  9:24         ` Masami Hiramatsu
2013-12-03 15:58           ` David Ahern
2013-12-04  1:22             ` Masami Hiramatsu
2013-12-04  1:44               ` David Ahern
2013-12-04  7:39                 ` Masami Hiramatsu
2013-12-08 17:50                   ` David Ahern
2013-12-02  5:59 ` [PATCH 1/2] perf probe: Improve error message when function not found Masami Hiramatsu
2013-12-02 14:52   ` David Ahern
2013-12-03  5:12     ` Masami Hiramatsu
2013-12-03 15:15       ` David Ahern
2013-12-04  1:23         ` Masami Hiramatsu

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=529CC97A.6000807@gmail.com \
    --to=dsahern@gmail.com \
    --cc=acme@ghostprotocols.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=masami.hiramatsu.pt@hitachi.com \
    --cc=namhyung@kernel.org \
    --cc=oleg@redhat.com \
    --cc=srikar@linux.vnet.ibm.com \
    --cc=yrl.pp-manager.tt@hitachi.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.