Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753830AbdFSTAK (ORCPT ); Mon, 19 Jun 2017 15:00:10 -0400 Received: from mx1.redhat.com ([209.132.183.28]:39966 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751668AbdFSTAH (ORCPT ); Mon, 19 Jun 2017 15:00:07 -0400 DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 271404E4D0 Authentication-Results: ext-mx09.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx09.extmail.prod.ext.phx2.redhat.com; spf=pass smtp.mailfrom=acme@redhat.com DKIM-Filter: OpenDKIM Filter v2.11.0 mx1.redhat.com 271404E4D0 Date: Mon, 19 Jun 2017 15:59:39 -0300 From: Arnaldo Carvalho de Melo To: Milian Wolff Cc: Jan Kratochvil , Namhyung Kim , "linux-kernel@vger.kernel.org" , linux-perf-users , David Ahern , Peter Zijlstra , Yao Jin , Jiri Olsa Subject: Re: perf report: fix off-by-one for non-activation frames Message-ID: <20170619185939.GA2170@redhat.com> References: <20170515150444.6841-1-milian.wolff@kdab.com> <20170617080402.GA1402@host1.jankratochvil.net> <1916323.ygRLzu1ryd@agathebauer> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1916323.ygRLzu1ryd@agathebauer> X-Url: http://acmel.wordpress.com User-Agent: Mutt/1.5.20 (2009-12-10) X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.38]); Mon, 19 Jun 2017 18:59:47 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 1058 Lines: 23 Em Sat, Jun 17, 2017 at 01:13:11PM +0200, Milian Wolff escreveu: > On Samstag, 17. Juni 2017 10:04:02 CEST Jan Kratochvil wrote: > > On Sat, 17 Jun 2017 09:56:57 +0200, Namhyung Kim wrote: > > > Not sure whether it needs be fixed or not. If we fix it, srcline and > > > address would not match so it can give its own confusion to users. > > > Ideally it should display an addressof the instruction before the > > > address IMHO. > > > > One can figure million ways how it can behave and each one has its pros and > > cons. I was just describing the current behavior of GDB and LLDB which > > people are used to already. > > Personally, I agree with Jan that we should mimick existing tool's behavior. I > just fear that it's not trivial to do it with the current code base... But we agree it is a worthwhile change (have backtraces in perf match what gdb, etc show), right? If you can, please try to do this, your attempt will help us understand more the extent of the changes needed and perhaps someonw can come up with simplifications... - Arnaldo