From: Arnaldo Carvalho de Melo <arnaldo.melo@gmail.com>
To: Jiri Olsa <jolsa@redhat.com>
Cc: Ivan Babrou <ivan@cloudflare.com>,
linux-kernel <linux-kernel@vger.kernel.org>,
linux-perf-users@vger.kernel.org,
Peter Zijlstra <peterz@infradead.org>,
Ingo Molnar <mingo@redhat.com>,
Alexander Shishkin <alexander.shishkin@linux.intel.com>,
Namhyung Kim <namhyung@kernel.org>,
kernel-team <kernel-team@cloudflare.com>
Subject: Re: perf is unable to read dward from go programs
Date: Fri, 29 Nov 2019 12:14:36 -0300 [thread overview]
Message-ID: <20191129151436.GB26963@kernel.org> (raw)
In-Reply-To: <20191129134929.GA26903@krava>
Em Fri, Nov 29, 2019 at 02:49:29PM +0100, Jiri Olsa escreveu:
> On Wed, Nov 27, 2019 at 01:15:20PM -0800, Ivan Babrou wrote:
> > There were no response in linux-perf-users@, so I think it's fair to
> > ask maintainers.
> >
> > On Fri, Nov 8, 2019 at 3:53 PM Ivan Babrou <ivan@cloudflare.com> wrote:
> > >
> > > I have a simple piece of code that burns CPU for 1s:
> > >
> > > * https://gist.github.com/bobrik/cf022ff6950d09032fa13a984e2272ed
> > >
> > > I can build it just fine: go build -o /tmp/burn burn.go
> > >
> > > And I can see correct stacks if I record with fp:
> > >
> > > perf record -e cpu-clock -g -F 99 /tmp/burn
> > >
> > > But if I record with gwarf:
> > >
> > > perf record -e cpu-clock -g -F 99 --call-graph dwarf /tmp/burn
> > >
> > > Then stacks are lost with the following complaints during "perf script":
> > >
> > > BFD: Dwarf Error: found dwarf version '376', this reader only handles
> > > version 2, 3 and 4 information.
> > > BFD: Dwarf Error: found dwarf version '31863', this reader only
> > > handles version 2, 3 and 4 information.
> > > BFD: Dwarf Error: found dwarf version '65271', this reader only
> > > handles version 2, 3 and 4 information.
> > > BFD: Dwarf Error: found dwarf version '289', this reader only handles
> > > version 2, 3 and 4 information.
>
> hi,
> the binary generated by go has compressed debug info (on my setup)
> and libunwind (default dwarf unwinder) does not seem to support that
>
> but when I compile perf with libdw unwind support:
>
> $ make DEBUG=1 VF=1 NO_LIBUNWIND=1
>
> I'm getting proper backtraces (below), maybe it's time to change
> the default dwarf unwinder ;-)
we have some 'perf test' entries testing the unwinding routines, can you
please check if those pass when switching to libdw's unwinder?
- Arnaldo
> thanks,
> jirka
>
>
> ---
> 51.63% ex ex [.] crypto/sha512.blockAVX2
> |
> ---crypto/sha512.blockAVX2
> |
> --51.48%--crypto/sha512.block
> crypto/sha512.(*digest).Write
> crypto/sha512.(*digest).checkSum
> crypto/sha512.(*digest).Sum
> main.burn
> main.main
> runtime.main
> runtime.goexit
>
> 11.55% ex ex [.] runtime.mallocgc
> |
> ---runtime.mallocgc
> |
> |--7.45%--runtime.newobject
> | |
> | --7.45%--main.burn
> | main.main
> | runtime.main
> | runtime.goexit
> |
> --3.40%--runtime.growslice
> crypto/sha512.(*digest).Sum
> main.burn
> main.main
> runtime.main
> runtime.goexit
>
> 3.69% ex ex [.] crypto/sha512.(*digest).Write
> |
> ---crypto/sha512.(*digest).Write
> |
> |--2.91%--crypto/sha512.(*digest).checkSum
> | crypto/sha512.(*digest).Sum
> | main.burn
> | main.main
> | runtime.main
> | runtime.goexit
> |
> --0.57%--main.burn
> main.main
> runtime.main
> runtime.goexit
>
> 3.44% ex ex [.] runtime.memclrNoHeapPointers
> |
> ---runtime.memclrNoHeapPointers
> |
> --2.92%--runtime.(*mheap).alloc
> runtime.(*mcentral).grow
> runtime.(*mcentral).cacheSpan
> runtime.(*mcache).refill
> runtime.(*mcache).nextFree
> runtime.mallocgc
> |
> |--2.27%--runtime.newobject
> | main.burn
> | main.main
> | runtime.main
> | runtime.goexit
> |
> --0.64%--runtime.growslice
> crypto/sha512.(*digest).Sum
> main.burn
> main.main
> runtime.main
> runtime.goexit
> ...
--
- Arnaldo
next prev parent reply other threads:[~2019-11-29 15:14 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <CABWYdi2jvPUq128XDv_VbY=vFknFyJHbUR=0_K9WuA0mFTkPvg@mail.gmail.com>
2019-11-27 21:15 ` perf is unable to read dward from go programs Ivan Babrou
2019-11-29 13:49 ` Jiri Olsa
2019-11-29 15:14 ` Arnaldo Carvalho de Melo [this message]
2019-12-02 19:49 ` Ivan Babrou
2019-12-03 10:22 ` Jiri Olsa
2019-12-19 23:38 ` Ivan Babrou
2019-12-19 23:57 ` Ivan Babrou
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20191129151436.GB26963@kernel.org \
--to=arnaldo.melo@gmail.com \
--cc=alexander.shishkin@linux.intel.com \
--cc=ivan@cloudflare.com \
--cc=jolsa@redhat.com \
--cc=kernel-team@cloudflare.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-perf-users@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=namhyung@kernel.org \
--cc=peterz@infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).