Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751852AbdFOTVC (ORCPT ); Thu, 15 Jun 2017 15:21:02 -0400 Received: from mx1.redhat.com ([209.132.183.28]:36258 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750793AbdFOTVA (ORCPT ); Thu, 15 Jun 2017 15:21:00 -0400 DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 66F8280C11 Authentication-Results: ext-mx02.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx02.extmail.prod.ext.phx2.redhat.com; spf=pass smtp.mailfrom=jan.kratochvil@redhat.com DKIM-Filter: OpenDKIM Filter v2.11.0 mx1.redhat.com 66F8280C11 Date: Thu, 15 Jun 2017 21:20:53 +0200 From: Jan Kratochvil To: Jiri Olsa Cc: Arnaldo Carvalho de Melo , Milian Wolff , Linux-kernel@vger.kernel.org, linux-perf-users@vger.kernel.org, Namhyung Kim , acme@kernel.org Subject: Re: [PATCH 2/2] perf report: report module before querying isactivation in dwfl unwind Message-ID: <20170615192053.GA4615@host1.jankratochvil.net> References: <20170602143753.16907-1-milian.wolff@kdab.com> <20170602143753.16907-2-milian.wolff@kdab.com> <20170602152508.GC7901@redhat.com> <20170605104720.GC28871@krava> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170605104720.GC28871@krava> User-Agent: Mutt/1.8.0 (2017-02-23) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.26]); Thu, 15 Jun 2017 19:21:00 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1021 Lines: 25 On Mon, 05 Jun 2017 12:47:20 +0200, Jiri Olsa wrote: > On Fri, Jun 02, 2017 at 12:25:08PM -0300, Arnaldo Carvalho de Melo wrote: > > Em Fri, Jun 02, 2017 at 04:37:53PM +0200, Milian Wolff escreveu: > > > The PC returned by dwfl_frame_pc may map into a not-yet-reported > > > module. We have to report it before we continue unwinding. But when > > > we query for the isactivation flag in dwfl_frame_pc, libdw will > > > actually do one more unwinding step internally which can then break > > > and lead to missed frames or broken stacks. > > > > > > With libunwind we get e.g.: > > sounds like a libdw design issue.. Jan is there a specific way > to handle the case that Milian described? I agree with the patch. Just be aware for performance then the __report_module() call in entry() is no longer useful as the '--pc' adjustment should never cross a module boundary. Although for perf unwinding performance there is still a wide gap there (such as caching the loaded modules for multiple backtraces.) Thanks, Jan