Re: [RFC] perf tool improvement requests

[Arnaldo Carvalho de Melo <acme@kernel.org>]

Em Tue, Sep 04, 2018 at 04:17:24PM +0200, Peter Zijlstra escreveu:
> On Tue, Sep 04, 2018 at 10:42:18AM -0300, Arnaldo Carvalho de Melo wrote:
> > 	Then I need to get the DW_AT_location stuff parsed in pahole, so
> > that with those offsets (second column, ending with :) with hits (first
> > column, there its local period, but we can ask for some specific metric
> > [1]), I'll be able to figure out what DW_TAG_variable or
> > DW_TAG_formal_parameter is living there at that time, get the offset
> > from the decoded instruction, say that xor, 0x138 offset from the type
> > for %r15 at that offset (85) from kmem_cache_alloc, right?
> 
> I'm not sure how the DWARF location stuff works; it could be it already
> includes the offset and decoding the instruction is not needed.
> 
> But yes, that's the basic idea; get DWARF to tell you what variable is
> used at a certain IP.
> 
> > In a first milestone we'd have something like:
> > 
> > 	perf annotate --hits function | pahole --annotate -C task_struct
> > 
> > 	perf annotate --hits | pahole --annotate
> 
> Not sure keeping it two proglets makes sense, but whatever :-)

This is just a start, trying to take advantage of existing codebases.
 
> The alternative I suppose is making perf do the IP->struct::member
> mapping and freed that to pahole, which then only uses it to annotate
> the output.

So, what I'm trying to do now is to make perf get the samples associated
with functions/offsets + decoded instructions.

Pahole, that already touches DWARF info, will just use the
DW_AT_location, look at its description, from
https://blog.tartanllama.xyz/writing-a-linux-debugger-variables/:


-------------------
    Simple location descriptions describe the location of one contiguous
piece (usually all) of an object. A simple location description may
describe a location in addressable memory, or in a register, or the lack
of a location (with or without a known value).

        Example:

            DW_OP_fbreg -32

	    A variable which is entirely stored -32 bytes from the stack
            frame base.

  Composite location descriptions describe an object in terms of pieces,
each of which may be contained in part of a register or stored in a
memory location unrelated to other pieces.

        Example:

            DW_OP_reg3 DW_OP_piece 4 DW_OP_reg10 DW_OP_piece 2

	    A variable whose first four bytes reside in register 3 and
            whose next two bytes reside in register 10.

   Location lists describe objects which have a limited lifetime or change
location during their lifetime.

        Example:
            <loclist with 3 entries follows>
                [ 0]<lowpc=0x2e00><highpc=0x2e19>DW_OP_reg0
                [ 1]<lowpc=0x2e19><highpc=0x2e3f>DW_OP_reg3
                [ 2]<lowpc=0x2ec4><highpc=0x2ec7>DW_OP_reg2

	    A variable whose location moves between registers depending
            on the current value of the program counter
-------------------


So I have a list of DW_TAG_formal_parameter (function parameters) and
DW_TAG_variable, and the above location lists/descriptions, stating in
what registers and what IP ranges the variables are in, and in the
DW_TAG_{formal_parameter,variable} I have DW_AT_type, that points to the
type of that variable, couple that with the offset taken from the
decoded instruction we get from 'perf annotate --hits' and we should
have all we need, no?

Then pahole can have all this painted on structs (like 'perf annotate')
for the whole workload, or for specific callchains, etc.

> Or, munge the entirety of pahole into perf..

That may be interesting at some point, yes.

- Arnaldo