lkml.org 
[lkml]   [2011]   [Mar]   [31]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
SubjectRe: [RFC PATCH] perf report: add sort by file lines
From
Date
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,
>
>




\
 
 \ /
  Last update: 2011-03-31 10:49    [from the cache]
©2003-2011 Jasper Spaans