[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Date: Tue, 6 Jun 2017 16:52:28 -0300
From: Arnaldo Carvalho de Melo <acme@...nel.org>
To: Milian Wolff <milian.wolff@...b.com>
Cc: Namhyung Kim <namhyung@...nel.org>,
"linux-kernel@...r.kernel.org" <Linux-kernel@...r.kernel.org>,
linux-perf-users <linux-perf-users@...r.kernel.org>,
Arnaldo Carvalho de Melo <acme@...hat.com>,
David Ahern <dsahern@...il.com>,
Peter Zijlstra <a.p.zijlstra@...llo.nl>,
Yao Jin <yao.jin@...ux.intel.com>, kernel-team@....com
Subject: Re: [PATCH 6/7] perf report: mark inlined frames in output by "
(inlined)" suffix
Em Tue, Jun 06, 2017 at 09:26:47AM +0200, Milian Wolff escreveu:
> On Tuesday, June 6, 2017 3:33:49 AM CEST Namhyung Kim wrote:
> > On Sat, Jun 3, 2017 at 10:51 PM, Milian Wolff <milian.wolff@...b.com> wrote:
> > > The current API seems to pass the data around mostly using the
> > > addr_location struct, which is usually constructed on the stack and not
> > > always memset to zero. As such, my initial plan of adding a srcline
> > > member there would require me to go through all the code to ensure that
> > > we memset the struct to zero...
> > > Alternatively, I'd have to change the API of hist_iter_ops, to let the
> > > callback take another `const char **srcline` out parameter. This is also
> > > going to be quite a large invasive change.
> > > Do you have any suggestions on how to make this work?
> > I think passing srcline via addr_location might not be very invasive
> > since it calls machine__resolve() in most cases. Missing places that
> > set al->sym should set al->srcline as well IMHO.
I haven't looked if it would be invasive or not, good that it isn't, but
then I think addr_location is the right place for this to be stored.
> OK, perfect - I'll implement that then.
Thanks,
- Arnaldo
Powered by blists - more mailing lists