perf tools vs go dwarf

[Albert Strasheim]

Howdy

I'm trying to get some of the perf tools working with Go binaries from tip.

There's some interesting things happening in Linux kernel land that could be useful for tracing Go binaries:

https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=fb7345bbf7fad9bf72ef63a19c707970b9685812

Latest attempt with the recently released 3.14 kernel.

This works:

perf probe -x `which perf` --line show_line_range

but it crashes on something like the output of go test -c http:

~/bin/perf probe -x ./http.test --line findrunnable
Segmentation fault (core dumped)

Backtrace from GDB:

#0  strlen () at ../sysdeps/x86_64/strlen.S:106

#1  0x000000000046b652 in strtailcmp (s1=s1@entry=0x7ffff79b030a "/home/albert/go/src/pkg/runtime/compiler.go", s2=0x0) at util/string.c:308

#2  0x00000000004c0d21 in line_range_walk_cb (fname=0x7ffff79b030a "/home/albert/go/src/pkg/runtime/compiler.go", lineno=1, addr=<optimized out>, data=0x7fffffffd2b0) at util/probe-finder.c:1549

#3  0x00000000004c3df6 in die_walk_lines (rt_die=rt_die@entry=0x7fffffffd158, callback=callback@entry=0x4c0cf0 <line_range_walk_cb>, data=data@entry=0x7fffffffd2b0) at util/dwarf-aux.c:714

#4  0x00000000004bfe7a in find_line_range_by_line (lf=0x7fffffffd2b0, sp_die=0x7fffffffd158) at util/probe-finder.c:1564

#5  line_range_search_cb (sp_die=0x7fffffffd158, data=0x7fffffffd280) at util/probe-finder.c:1619

#6  0x000000396081459d in walk_children () at libdw_visit_scopes.c:121

#7  0x0000003960813fda in __libdw_visit_scopes (depth=depth@entry=0, root=<optimized out>, previsit=previsit@entry=0x3960812e90 <tree_visitor>, postvisit=postvisit@entry=0x0, arg=arg@entry=0x7fffffffd1b0) at libdw_visit_scopes.c:146

#8  0x0000003960813037 in dwarf_getfuncs (cudie=cudie@entry=0x7fffffffd2c8, callback=callback@entry=0x4bfd60 <line_range_search_cb>, arg=arg@entry=0x7fffffffd280, offset=offset@entry=0) at dwarf_getfuncs.c:111

#9  0x00000000004c1c10 in find_line_range_by_func (lf=0x7fffffffd2b0) at util/probe-finder.c:1628

#10 debuginfo__find_line_range (dbg=dbg@entry=0x906cd0, lr=lr@entry=0x8448f8 <params+9240>) at util/probe-finder.c:1677

#11 0x00000000004a269d in show_line_range (lr=lr@entry=0x8448f8 <params+9240>, module=<optimized out>) at util/probe-event.c:586

#12 0x000000000043b78b in __cmd_probe (argc=<optimized out>, argv=argv@entry=0x7fffffffdca0, prefix=<optimized out>) at builtin-probe.c:465

#13 0x000000000043bad7 in cmd_probe (argc=<optimized out>, argv=0x7fffffffdca0, prefix=<optimized out>) at builtin-probe.c:519

#14 0x000000000041a6b5 in run_builtin (p=p@entry=0x7eef00 <commands+384>, argc=argc@entry=5, argv=argv@entry=0x7fffffffdca0) at perf.c:319

#15 0x0000000000419f50 in handle_internal_command (argv=0x7fffffffdca0, argc=5) at perf.c:376

#16 run_argv (argv=0x7fffffffdaa0, argcp=0x7fffffffdaac) at perf.c:420

#17 main (argc=5, argv=0x7fffffffdca0) at perf.c:529

perf code:

https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/tools/perf?id=v3.14

In my experience so far, these crashes are caused by problems with the DWARF info.

Regards

Albert

[Dave Cheney]

On Thu, Apr 3, 2014 at 6:05 PM, Albert Strasheim <ful...@gmail.com> wrote:
> Howdy
>
> I'm trying to get some of the perf tools working with Go binaries from tip.
>
> There's some interesting things happening in Linux kernel land that could be
> useful for tracing Go binaries:
>
> https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/commit/?id=fb7345bbf7fad9bf72ef63a19c707970b9685812
>
> Latest attempt with the recently released 3.14 kernel.
>
> This works:
>
> perf probe -x `which perf` --line show_line_range
>
> but it crashes on something like the output of go test -c http:
>
> ~/bin/perf probe -x ./http.test --line findrunnable
> Segmentation fault (core dumped)
>
> Backtrace from GDB:
>
> #0 strlen () at ../sysdeps/x86_64/strlen.S:106
> #1 0x000000000046b652 in strtailcmp (s1=s1@entry=0x7ffff79b030a
> "/home/albert/go/src/pkg/runtime/compiler.go", s2=0x0) at util/string.c:308

This looks all messed up. compiler.go has one constant, runtime.Compiler.

Thanks for reporting this, I noticed something which is probably
related a few days ago but hadn't looked into it. Using objdump, the
jump targets for CALL instructions are all messed up.

> --
>
> ---
> You received this message because you are subscribed to the Google Groups
> "golang-dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to golang-dev+...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.