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
