linux-kernel - Re: [PATCH v2] perf report: distinguish between inliners in the same function

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Date:   Thu, 18 May 2017 14:20:10 +0200
From:   Milian Wolff <milian.wolff@...b.com>
To:     Namhyung Kim <namhyung@...nel.org>
Cc:     linux-kernel@...r.kernel.org, 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 v2] perf report: distinguish between inliners in the same function

On Mittwoch, 17. Mai 2017 08:13:16 CEST Namhyung Kim wrote:
> On Tue, May 16, 2017 at 03:18:13PM +0200, Milian Wolff wrote:
> > On Dienstag, 16. Mai 2017 02:53:32 CEST Namhyung Kim wrote:
> > > On Mon, May 15, 2017 at 12:01:54PM +0200, Milian Wolff wrote:
> > > > On Monday, May 15, 2017 3:21:58 AM CEST Namhyung Kim wrote:
> > > > > Hi Milian,
> > > > > 
> > > > > On Sun, May 14, 2017 at 08:10:50PM +0200, Milian Wolff wrote:
> > > > > > On Freitag, 12. Mai 2017 15:01:29 CEST Namhyung Kim wrote:
> > > > > I think you'd be better adding (fake) dso and sym to keep the inline
> > > > > information.  The fake dso can be paired with the original dso and
> > > > > maintain a tree of (inlined) symbols.  You may need a fake map to
> > > > > point the fake dso then.  It seems a bit compilcated but that way
> > > > > the
> > > > > code will be more consistent and easier to handle (e.g. for caching
> > > > > and/or deletion) IMHO.
> > > > 
> > > > Can you expand on this please? How would that solve the problem of
> > > > finding
> > > > a function name or srcline for a given inline frame?
> > > > 
> > > > I.e.: the function name is, currently, part of the sym. So the fake
> > > > dso/map
> > > > would contain an internal, fake, string table which fake symbols could
> > > > leverage for the function name?
> > > > 
> > > > Sounds like doable, but also sounds like *a lot* of work. And I don't
> > > > see
> > > > how that would solve the srcline situation: That one is queried
> > > > on-demand
> > > > based on the IP of a frame. I would say that inline frames should keep
> > > > the IP of the first non-inlined frame. But that would make it
> > > > impossible
> > > > to find the srcline for the N'th inlined frame... Am I missing
> > > > something?
> > > 
> > > I agree that srcline info can be kept in callchain cursor nodes, but I
> > > still think function name should be in (fake) symbols.  Sharing a
> > > symbol for all inlined frames would not work for the children mode
> > > IMHO.
> > 
> > I'm running into a bit of trouble here. I hoped to be able to store the
> > inlined symbol in the DSO to reuse it for other inlined entries that use
> > the same function. I also hope that this will then take care of the
> > deletion of the fake symbols, once the dso is freed.
> 
> I don't want to store inlined functions to an original DSO as it would
> confuse symbol lookups in the DSO.  As you said those inlined
> functions will have same address so multiple symbols exist for an
> address.
> 
> I thought they can be kept in a fake DSO which should be linked to the
> original DSO, but it doesn't need to be a DSO.  Instead a DSO can have
> a tree that maintains lists of (inlined) symbols and srclines sorted
> by address.

Thank you, this is what I'll be doing now.

Cheers

-- 
Milian Wolff | milian.wolff@...b.com | Software Engineer
KDAB (Deutschland) GmbH&Co KG, a KDAB Group company
Tel: +49-30-521325470
KDAB - The Qt Experts
Download attachment "smime.p7s" of type "application/pkcs7-signature" (5903 bytes)