Message-ID: <4BEC6DC2.4040207@redhat.com>
Date:	Thu, 13 May 2010 17:23:14 -0400
From:	Masami Hiramatsu <mhiramat@...hat.com>
To:	Arnaldo Carvalho de Melo <acme@...stprotocols.net>
CC:	Chase Douglas <chase.douglas@...onical.com>,
	linux-kernel@...r.kernel.org,
	Peter Zijlstra <a.p.zijlstra@...llo.nl>,
	Paul Mackerras <paulus@...ba.org>, Ingo Molnar <mingo@...e.hu>
Subject: Re: perf: relative path to source for perf probe?

Arnaldo Carvalho de Melo wrote:
> Em Thu, May 13, 2010 at 06:01:10PM +0200, Chase Douglas escreveu:
>> On Thu, May 13, 2010 at 4:58 PM, Arnaldo Carvalho de Melo
>> <acme@...stprotocols.net> wrote:
>>> Look in tools/perf/util/symbol.c, these variables are the ones tools use
>>> to govern how the symbol system work wrt finding vmlinux:
>>>
>>> symbol_conf.use_vmlinux_path
>>> symbol_conf.vmlinux_name
>>>
>>> In addition to this it will use what is in ~/.debug/ if it has a
>>> build-id in the perf.data header.
>>>
>>> The changes for support kvm also touched this and allow for some
>>> prefixing to look for guest symbols, generalizing that to make guest
>>> kernel vmlinux + modules relative location be reused to look for
>>> relative location for host kernel vmlinux + modules seems the way to go.
>>
>> After reading this some more, I think we are talking about two
>> different things. I think your notes above are referring to locating
>> the vmlinux image and other debug symbols. This seems to work fine for
>> me using the -k flag.
> 
> What about finding the associated modules?
> 
>> However, I'm encountering an issue where the source code location
>> isn't found. I think this is fairly specific to the probe command of
>> perf, which is fairly new, so maybe it's missing the same level of
>> support that the symbol finding code has?
> 
> Annotation needs it, in top, report, too.
> 
> But probably (haven't looked at the sources) the way to specify it will
> be different, since we rely on objdump to do the disassembly, we need to
> inform it where the sources are, but look at the source of all this, the
> relevant DWARF tags:
> 
>  <0><b>: Abbrev Number: 1 (DW_TAG_compile_unit)
>     < c>   DW_AT_stmt_list   : 0x0      
>     <10>   DW_AT_ranges      : 0x0      
>     <14>   DW_AT_name        : /home/acme_unencrypted/git/linux-2.6-tip/arch/x86/kernel/head_64.S       
>     <57>   DW_AT_comp_dir    : /home/acme_unencrypted/git/build/v2.6.34-rc6-

Actually, these doesn't help us so much. DW_AT_name shows the absolute path
of source file (and perf probe already have it), and DW_AT_comp_dir just 
shows where the object code has been stored (or where the make command ran).

In this case (after compiling kernel, user moved its source into another
directory), we have to find the top directory of this source code.

Imagine that, if user compiled code under /home/user/git-ksrc/, and 
it was moved under  /usr/src/2.6.x/, perf probe will be given an option
'-s /usr/src/2.6.x/'.

If we know the top directory is /home/user/git-ksrc/, we can replace
it with /usr/src/2.6.x/. However, dwarf doesn't provide this information.
So we need to assume that where is the top directory in absolute path.

I think, we can do it by brute force (I'm not sure how gdb does it).

Replace the root directory with given directory and try to open it.

 fopen("/usr/src/2.6.x/" "home/user/git-ksrc/kernel/kprobes.c"); -> NG

If there is no file exist, remove next directory and add given directory
and try to open it again.

 fopen("/usr/src/2.6.x/" "user/git-ksrc/kernel/kprobes.c"); -> NG

And repeat it until the file exist.

 fopen("/usr/src/2.6.x/" "git-ksrc/kernel/kprobes.c"); -> NG

 fopen("/usr/src/2.6.x/" "kernel/kprobes.c"); -> OK!


Thank you,

-- 
Masami Hiramatsu
e-mail: mhiramat@...hat.com
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists