Messages in this thread | | | Subject | Re: [RFC PATCH] perf report: add sort by file lines | From | Lin Ming <> | Date | Thu, 31 Mar 2011 16:45:55 +0800 |
| |
On Wed, 2011-03-30 at 09:04 +0800, Masami Hiramatsu wrote: > (2011/03/30 2:45), Arnaldo Carvalho de Melo wrote: > > Em Tue, Mar 29, 2011 at 07:08:53PM +0200, Peter Zijlstra escreveu: > >> On Tue, 2011-03-29 at 19:06 +0200, Peter Zijlstra wrote: > >>> On Tue, 2011-03-29 at 19:03 +0200, Peter Zijlstra wrote: > >>>>> Is it an unwind of the call frame stack to find out what data member was > >>>>> accessed? > > > >>>> No need to unwind stacks, DWARF should have information on function > >>>> local stack. It should be able to tell you the type of things like -8(% > >>>> rbp). > > > >>> That is, we don't even have a life stack to unwind, so we simply cannot > >>> unwind at all, but the debug information should be able to tell you the > >>> type of whatever would live at a certain stack position if we were to > >>> have a stack. > > > >> Furthermore, I've now completely exhausted my knowledge of debuginfo and > >> hope Masami and Arnaldo will help with further details ;-) > > > > :-) > > > > I think the place to look is 'perf probe', look for the way one > > variable is translated to an expression passed to the kprobe_tracer, I > > think you'll need the reverse operation. > > > > Look at tools/perf/util/probe-finder.c, function find_variable() and > > convert_variable_location(). > > Right, perf probe is available for looking up a variable at > an address, however, since it just depends on the dwarf, > we can just know the mapping from (actual) variables to > locations (registers/stacks etc.) > > It seems that Peter requires more than that, his request is > getting a map from (temporarily used) register to a specific > member of a data structure pointed by a pointer. But dwarf is > not enough for that. > > Peter gave us a good example of that. > > > void foo(struct foo *foo, struct tmp *tmp) > > { > > foo->bar->fubar = tmp->blah; > > } > > > > foo: > > .cfi_startproc > > pushq %rbp > > .cfi_def_cfa_offset 16 > > movq %rsp, %rbp > > .cfi_offset 6, -16 > > .cfi_def_cfa_register 6 > > movq %rdi, -8(%rbp) > > movq %rsi, -16(%rbp) > > movq -8(%rbp), %rax /* load foo arg from stack */ > > movq 24(%rax), %rax /* load foo->bar */ > > movq -16(%rbp), %rdx /* load tmp arg from stack */ > > movl 32(%rdx), %edx /* load tmp->blah */ > > movl %edx, 20(%rax) /* store bar->fubar */ <<==(1) > > leave > > ret > > .cfi_endproc > > At (1), dwarf tells us the location of 'foo' is -8(%rbp) and 'tmp' is > -16(%rbp), but doesn't know to what 20(%rax) is mapped, because > foo->bar->fubar is not a real variable.
I am considering if it is possible to do "instruction unwind" to get a map from (temporarily used) register to a specific member of a data structure pointed by a pointer.
4004a0: movq -8(%rbp), %rax /* load foo arg from stack */ 4004a4: movq 24(%rax), %rax /* load foo->bar */ 4004a8: movq -16(%rbp), %rdx /* load tmp arg from stack */ 4004ac: movl 32(%rdx), %edx /* load tmp->blah */ 4004af: movl %edx, 20(%rax) /* store bar->fubar */
foo: -8(%rbp) tmp: -16(%rbp)
Assume we are now at ip 4004af, from the instruction decoder, we know it's a store operation, and we want to find out what %rax is.
1. unwind to 4004ac Ignore this, because it does not touch %rax
2. unwind to 4004a8 Ignore this, because it does not touch %rax
3. unwind to 4004a4 20(%rax) => 20(24(%rax)), continue to unwind because we still have no idea what %rax is
4. unwind to 4004a0 20(24(%rax)) => 20(24(-8(%rbp))), stop unwind, because we now know -8(%rbp) is foo.
So the original 20(%rax) is replace as 20(24(-8(%rbp))), and it means foo->bar->fubar
Does this make sense?
Thanks, Lin Ming
> > So that what we need is a kind of the reverse compiler which generates > intermediate code (a sequence of register assignments) from > instruction code. That's not impossible task, but just hard and fun. :) > For that purpose, we'll need an instruction decoder and an evaluator > which allows us to trace the sequence of address dereferences. > > Anyway, I'd recommend that we should start with just showing > the corresponding "source line" of the address. It may be > enough for some cases. > > Thank you, > >
| |