From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-kernel-owner@vger.kernel.org>
Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand
	id S1753308AbbIATVu (ORCPT <rfc822;w@1wt.eu>);
	Tue, 1 Sep 2015 15:21:50 -0400
Received: from mail.kernel.org ([198.145.29.136]:36173 "EHLO mail.kernel.org"
	rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP
	id S1750889AbbIATVt (ORCPT <rfc822;linux-kernel@vger.kernel.org>);
	Tue, 1 Sep 2015 15:21:49 -0400
Date: Tue, 1 Sep 2015 16:21:44 -0300
From: Arnaldo Carvalho de Melo <acme@kernel.org>
To: Andi Kleen <ak@linux.intel.com>
Cc: Andi Kleen <andi@firstfloor.org>, linux-kernel@vger.kernel.org,
        jolsa@kernel.org
Subject: Re: [PATCH] perf, tools: Always use non inlined file name for srcfile
Message-ID: <20150901192144.GA25466@kernel.org>
References: <1441131102-28331-1-git-send-email-andi@firstfloor.org>
 <20150901183657.GG29821@kernel.org>
 <20150901184839.GA4524@tassilo.jf.intel.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20150901184839.GA4524@tassilo.jf.intel.com>
X-Url: http://acmel.wordpress.com
User-Agent: Mutt/1.5.23 (2014-03-12)
Sender: linux-kernel-owner@vger.kernel.org
List-ID: <linux-kernel.vger.kernel.org>
X-Mailing-List: linux-kernel@vger.kernel.org

Em Tue, Sep 01, 2015 at 11:48:39AM -0700, Andi Kleen escreveu:
> On Tue, Sep 01, 2015 at 03:36:57PM -0300, Arnaldo Carvalho de Melo wrote:
> > Em Tue, Sep 01, 2015 at 11:11:42AM -0700, Andi Kleen escreveu:
> > > From: Andi Kleen <ak@linux.intel.com>
> > > 
> > > When profiling the kernel with srcfile it's common to "get
> > > stuck" in include. For example a lot of code uses current
> > > or other inlines, so they get accounted to some random
> > > include file. This is not very useful as a high level
> > > categorization.
> > 
> > Cool idea :-)
> 
> Yes.
> 
> It would be also nice to use this information for unwinding
> (so to show the inline stack as part of the call graph)

Yes, agreed.

> > Why not the so much simpler:
> > 
> > 		while (bfd_find_inliner_info(...));
> > 
> > But other than that, wouldn't be better to put an upper limit on this?
> > 
> > Say, 1024 levels of unwinding to avoid tripping in some bfd lib bug that
> > could make this function always return true and make addr2line get stuck
> > in an infinite loop?
> 
> Done. I sent a v2.

Thanks, I applied v2.

- Arnaldo