[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20191129151436.GB26963@kernel.org>
Date: Fri, 29 Nov 2019 12:14:36 -0300
From: Arnaldo Carvalho de Melo <arnaldo.melo@...il.com>
To: Jiri Olsa <jolsa@...hat.com>
Cc: Ivan Babrou <ivan@...udflare.com>,
linux-kernel <linux-kernel@...r.kernel.org>,
linux-perf-users@...r.kernel.org,
Peter Zijlstra <peterz@...radead.org>,
Ingo Molnar <mingo@...hat.com>,
Alexander Shishkin <alexander.shishkin@...ux.intel.com>,
Namhyung Kim <namhyung@...nel.org>,
kernel-team <kernel-team@...udflare.com>
Subject: Re: perf is unable to read dward from go programs
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@...udflare.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
Powered by blists - more mailing lists