Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
Date:   Tue, 4 Sep 2018 11:35:07 -0300
From:   Arnaldo Carvalho de Melo <acme@kernel.org>
To:     Peter Zijlstra <peterz@infradead.org>
Cc:     Stephane Eranian <eranian@google.com>,
        Jiri Olsa <jolsa@redhat.com>, Jiri Olsa <jolsa@kernel.org>,
        LKML <linux-kernel@vger.kernel.org>,
        Namhyung Kim <namhyung@kernel.org>
Subject: Re: [RFC] perf tool improvement requests
Message-ID: <20180904143507.GC5364@kernel.org>
References: <CABPqkBT0kEMOnTw1-E1kezCvtWNSws7dp2qzCWKVmjGPOEga8Q@mail.gmail.com>
 <20180904071049.GY24124@hirez.programming.kicks-ass.net>
 <20180904134218.GA5364@kernel.org>
 <20180904141724.GJ24124@hirez.programming.kicks-ass.net>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20180904141724.GJ24124@hirez.programming.kicks-ass.net>
User-Agent: Mutt/1.9.2 (2017-12-15)
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

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