Messages in this thread | | | Date | Tue, 4 Sep 2018 11:35:07 -0300 | From | Arnaldo Carvalho de Melo <> | 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
| |