[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20180904143507.GC5364@kernel.org>
Date: Tue, 4 Sep 2018 11:35:07 -0300
From: Arnaldo Carvalho de Melo <acme@...nel.org>
To: Peter Zijlstra <peterz@...radead.org>
Cc: Stephane Eranian <eranian@...gle.com>,
Jiri Olsa <jolsa@...hat.com>, Jiri Olsa <jolsa@...nel.org>,
LKML <linux-kernel@...r.kernel.org>,
Namhyung Kim <namhyung@...nel.org>
Subject: Re: [RFC] perf tool improvement requests
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
Powered by blists - more mailing lists