public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com>
To: Prashanth Nageshappa <prashanth@linux.vnet.ibm.com>
Cc: mingo@elte.hu, linux-kernel@vger.kernel.org, acme@infradead.org,
	ananth@in.ibm.com, Srikar Dronamraju <srikar@linux.vnet.ibm.com>,
	rostedt@goodmis.org
Subject: Re: [RESEND]Re: [PATCH] perf - probe finder fails to resolve function name to address
Date: Mon, 26 Mar 2012 19:51:10 +0900	[thread overview]
Message-ID: <4F704A1E.2040401@hitachi.com> (raw)
In-Reply-To: <4F703FB9.9020407@linux.vnet.ibm.com>

(2012/03/26 19:06), Prashanth Nageshappa wrote:
> Fixing a coding style issue..
> 
> On 03/23/2012 06:22 PM, Masami Hiramatsu wrote:
> 
>> Hi,
>>
>> (2012/03/22 19:23), Prashanth Nageshappa wrote:
>>> probe finder fails to resolve valid function names into addresses for
>>> functions which have more than one die entries in DWARF info.
>>>
>>> It is valid for DWARF info to contain more than 1 entries for a given
>>> function name, where one entry corresponds to definition which has code
>>> address/range attributes and remaining entries (which are only
>>> declarations) does not have code address/range attributes.
>>> (example: do_fork, sys_write, sys_wait4, sys_sync etc)
>>
>> Hmm, I'd like to reproduce and see what happened on debuginfo in those cases.
>> Could you tell me your environment or actual dwarf dump of those entries as below?
>>
> 
> $ uname -r
> 3.1.0-7.fc16.x86_64
> 
> $ sudo perf probe  do_fork
> Failed to get entry address of do_fork.
>   Error: Failed to add events. (-2)
> 
> $ readelf -wi /usr/lib/debug/lib/modules/3.1.0-7.fc16.x86_64/vmlinux | grep do_fork -A 16
>     <2691f7>   DW_AT_name        : (indirect string, offset: 0x1b1e0): do_fork	
>     <2691fb>   DW_AT_decl_file   : 3	
>     <2691fc>   DW_AT_decl_line   : 2269	
>     <2691fe>   DW_AT_prototyped  : 1	
>     <2691fe>   DW_AT_type        : <0x2593d1>	
>     <269202>   DW_AT_declaration : 1	

OK, compared with mine, this attribute is actually new one
for this kind of (declaration) entries.

[...]
>>
>> At least we must consider this lazy_line case. If I understand correctly,
>> that can also affect find_probe_point_lazy(sp_die, pf);
>>
>> If I find the different attribute, I'd like to add a checker function and
>> filter it out at early step in this function.
>>
> 
> Based on the above comments I have redone the patch:
> 
> If die entries corresponding to declarations appear before definition
> entry, probe finder returns error instead of continuing to look further
> for a definition entry.
> 
> This patch ensures we reach to the die entry corresponding to the
> definition and get the function address.
> 
> V2: A simpler solution based on Masami's suggestion.
> 
> 
> Signed-off-by: Prashanth Nageshappa <prashanth@linux.vnet.ibm.com>

Well, OK. This looks good for me too :)

Acked-by: Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com>

> ---
> 
>  tools/perf/util/probe-finder.c |    4 +++-
>  1 files changed, 3 insertions(+), 1 deletions(-)
> 
> diff --git a/tools/perf/util/probe-finder.c b/tools/perf/util/probe-finder.c
> index 5d73262..d5914ee 100644
> --- a/tools/perf/util/probe-finder.c
> +++ b/tools/perf/util/probe-finder.c
> @@ -963,10 +963,12 @@ static int probe_point_search_cb(Dwarf_Die *sp_die, void *data)
>  	struct dwarf_callback_param *param = data;
>  	struct probe_finder *pf = param->data;
>  	struct perf_probe_point *pp = &pf->pev->point;
> +	Dwarf_Attribute attr;
> 
>  	/* Check tag and diename */
>  	if (dwarf_tag(sp_die) != DW_TAG_subprogram ||
> -	    !die_compare_name(sp_die, pp->function))
> +	    !die_compare_name(sp_die, pp->function) ||
> +	    dwarf_attr(sp_die, DW_AT_declaration, &attr))
>  		return DWARF_CB_OK;
> 
>  	/* Check declared file */
> 
> 


-- 
Masami HIRAMATSU
Software Platform Research Dept. Linux Technology Center
Hitachi, Ltd., Yokohama Research Laboratory
E-mail: masami.hiramatsu.pt@hitachi.com

  reply	other threads:[~2012-03-26 10:51 UTC|newest]

Thread overview: 12+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <4F6AF410.1010400@linux.vnet.ibm.com>
2012-03-22 10:23 ` [PATCH] perf - probe finder fails to resolve function name to address Prashanth Nageshappa
2012-03-23 12:52   ` Masami Hiramatsu
2012-03-26  9:52     ` Prashanth Nageshappa
2012-03-26 10:06     ` [RESEND]Re: " Prashanth Nageshappa
2012-03-26 10:51       ` Masami Hiramatsu [this message]
2012-03-28 11:47         ` Ingo Molnar
2012-03-28 12:59           ` [PATCH] perf: missing export.h file Eric Dumazet
2012-03-28 14:35             ` Arnaldo Carvalho de Melo
2012-03-28 21:44             ` David Miller
2012-03-29  6:12               ` Ingo Molnar
2012-03-28 14:33           ` [RESEND]Re: [PATCH] perf - probe finder fails to resolve function name to address Arnaldo Carvalho de Melo
2012-03-31  7:44       ` [tip:perf/urgent] perf probe: Finder " tip-bot for Prashanth Nageshappa

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=4F704A1E.2040401@hitachi.com \
    --to=masami.hiramatsu.pt@hitachi.com \
    --cc=acme@infradead.org \
    --cc=ananth@in.ibm.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=prashanth@linux.vnet.ibm.com \
    --cc=rostedt@goodmis.org \
    --cc=srikar@linux.vnet.ibm.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox