Re: [RFC PATCH] perf report: add sort by file lines

[Lin Ming]

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,
> 
> 


--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/