[lkml]   [2018]   [Sep]   [4]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [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

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


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.


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.

<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

 \ /
  Last update: 2018-09-04 16:36    [W:0.043 / U:2.468 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site