Re: perf: relative path to source for perf probe?

[Masami Hiramatsu <mhiramat@redhat.com>]

Arnaldo Carvalho de Melo wrote:
> Em Thu, May 13, 2010 at 05:23:14PM -0400, Masami Hiramatsu escreveu:
>> 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@ghostprotocols.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).
> 
> IOW:
> 
> real_path = user_provided_path + (DW_AT_name - DW_AT_comp_dir)
> 
> + == concat
> 
> - remove initial string
> 
> if the project is build in place, i.e. in the kernel case, when one
> doesn't use 'make O='
> 
> But then, given user_provided_path what we can do is to find a match
> from the end of DW_AT_name, thus infering the missing (non-existent in
> DWARF) DW_AT_source_dir tag :-)

I recommend you to find a match from the top of DW_AT_name, because
we have many same-name files under kernel/ and arch/XXX/kernel/ :P


>> 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/'.
> 
> So, for the DW_AT_name example above, we would have these files:
> 
> At build time (DW_AT_name):
> 
> /home/acme_unencrypted/git/linux-2.6-tip/arch/x86/kernel/head_64.S
> 
> And at analysis time (using the path where the user moved all the source
> tree):
> 
> /usr/src/2.6.x/arch/x86/kernel/head_64.S
> 
> Putting then side by side:
> 
> /home/acme_unencrypted/git/linux-2.6-tip/arch/x86/kernel/head_64.S
>                           /usr/src/2.6.x/arch/x86/kernel/head_64.S
> 
> So know we know what DW_AT_source_dir is.

Sure :)

> 
> Implementation is left to the reader 8-)
> 
> - Arnaldo

Thank you,

-- 
Masami Hiramatsu
e-mail: mhiramat@redhat.com