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

[Arnaldo Carvalho de Melo <acme@ghostprotocols.net>]

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 :-)
 
> 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.

Implementation is left to the reader 8-)

- Arnaldo