From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752665AbdFQIEN (ORCPT ); Sat, 17 Jun 2017 04:04:13 -0400 Received: from mx1.redhat.com ([209.132.183.28]:57144 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752301AbdFQIEJ (ORCPT ); Sat, 17 Jun 2017 04:04:09 -0400 DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 7025CC0587CE Authentication-Results: ext-mx08.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx08.extmail.prod.ext.phx2.redhat.com; spf=pass smtp.mailfrom=jan.kratochvil@redhat.com DKIM-Filter: OpenDKIM Filter v2.11.0 mx1.redhat.com 7025CC0587CE Date: Sat, 17 Jun 2017 10:04:02 +0200 From: Jan Kratochvil To: Namhyung Kim Cc: Milian Wolff , "linux-kernel@vger.kernel.org" , linux-perf-users , Arnaldo Carvalho de Melo , David Ahern , Peter Zijlstra , Yao Jin , Jiri Olsa Subject: Re: perf report: fix off-by-one for non-activation frames Message-ID: <20170617080402.GA1402@host1.jankratochvil.net> References: <20170515150444.6841-1-milian.wolff@kdab.com> <5576772.scvU8aRrkq@agathebauer> <20170616115744.GA14948@host1.jankratochvil.net> <31894796.cyPb9Arfxd@agathebauer> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: 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.32]); Sat, 17 Jun 2017 08:04:09 +0000 (UTC) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org 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. Jan