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: [PATCH] perf - probe finder fails to resolve function name to address
Date: Fri, 23 Mar 2012 21:52:43 +0900	[thread overview]
Message-ID: <4F6C721B.9060807@hitachi.com> (raw)
In-Reply-To: <4F6AFD92.4030603@linux.vnet.ibm.com>

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?

$ readelf -wi vmlinux | grep do_fork -A 16

for example, on my fedora15, it shows;

    <3c68a3>   DW_AT_name        : (indirect string, offset: 0x201e0): do_fork_idle
    <3c68a7>   DW_AT_decl_file   : 2
    <3c68a8>   DW_AT_decl_line   : 631
    <3c68aa>   DW_AT_prototyped  : 1
    <3c68ab>   DW_AT_low_pc      : 0xffffffff817f0e25
    <3c68b3>   DW_AT_high_pc     : 0xffffffff817f0e47
    <3c68bb>   DW_AT_frame_base  : 1 byte block: 9c     (DW_OP_call_frame_cfa)
    <3c68bd>   DW_AT_sibling     : <0x3c68e2>
 <2><3c68c1>: Abbrev Number: 92 (DW_TAG_formal_parameter)
    <3c68c2>   DW_AT_name        : (indirect string, offset: 0x20a53d): work
    <3c68c6>   DW_AT_decl_file   : 2
--
    <672173>   DW_AT_name        : (indirect string, offset: 0x2d346): do_fork
    <672177>   DW_AT_decl_file   : 3
    <672178>   DW_AT_decl_line   : 1519
    <67217a>   DW_AT_prototyped  : 1
    <67217b>   DW_AT_type        : <0x65ab83>
    <67217f>   DW_AT_low_pc      : 0xffffffff8103cb40
    <672187>   DW_AT_high_pc     : 0xffffffff8103ce75
    <67218f>   DW_AT_frame_base  : 1 byte block: 9c     (DW_OP_call_frame_cfa)
    <672191>   DW_AT_sibling     : <0x6727bd>
 <2><672195>: Abbrev Number: 105 (DW_TAG_formal_parameter)
    <672196>   DW_AT_name        : (indirect string, offset: 0xc27d): clone_flags

I'd like to see what attribute was different in the case which you encountered.


> 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. I have also removed the
> warning as this is a valid thing to happen.
> 
> Signed-off-by: Prashanth Nageshappa <prashanth@linux.vnet.ibm.com>
> ---
> 
>  tools/perf/util/probe-finder.c |    5 +----
>  1 files changed, 1 insertions(+), 4 deletions(-)
> 
> diff --git a/tools/perf/util/probe-finder.c b/tools/perf/util/probe-finder.c
> index 5d73262..5e1e6f7 100644
> --- a/tools/perf/util/probe-finder.c
> +++ b/tools/perf/util/probe-finder.c
> @@ -984,10 +984,7 @@ static int probe_point_search_cb(Dwarf_Die *sp_die, void *data)
>  			param->retval = find_probe_point_lazy(sp_die, pf);

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.

>  		else {
>  			if (dwarf_entrypc(sp_die, &pf->addr) != 0) {
> -				pr_warning("Failed to get entry address of "
> -					   "%s.\n", dwarf_diename(sp_die));
> -				param->retval = -ENOENT;
> -				return DWARF_CB_ABORT;
> +				return DWARF_CB_OK;
>  			}
>  			pf->addr += pp->offset;
>  			/* TODO: Check the address in this function */
> 

Thank you,

-- 
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-23 12:52 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 [this message]
2012-03-26  9:52     ` Prashanth Nageshappa
2012-03-26 10:06     ` [RESEND]Re: " Prashanth Nageshappa
2012-03-26 10:51       ` Masami Hiramatsu
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=4F6C721B.9060807@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