From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 95673 invoked by alias); 22 Mar 2018 12:30:59 -0000 Mailing-List: contact elfutils-devel-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Post: List-Help: List-Subscribe: Sender: elfutils-devel-owner@sourceware.org Received: (qmail 95655 invoked by uid 89); 22 Mar 2018 12:30:58 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Checked: by ClamAV 0.99.4 on sourceware.org X-Virus-Found: No X-Spam-SWARE-Status: No, score=-24.9 required=5.0 tests=AWL,BAYES_00,GIT_PATCH_0,GIT_PATCH_1,GIT_PATCH_2,GIT_PATCH_3,KAM_LAZY_DOMAIN_SECURITY,RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.2 spammy= X-Spam-Status: No, score=-24.9 required=5.0 tests=AWL,BAYES_00,GIT_PATCH_0,GIT_PATCH_1,GIT_PATCH_2,GIT_PATCH_3,KAM_LAZY_DOMAIN_SECURITY,RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.2 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on sourceware.org X-Spam-Level: X-HELO: dd17628.kasserver.com Received: from dd17628.kasserver.com (HELO dd17628.kasserver.com) (85.13.138.83) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 22 Mar 2018 12:30:57 +0000 Received: from agathebauer.localnet (ip5f5bf42a.dynamic.kabel-deutschland.de [95.91.244.42]) by dd17628.kasserver.com (Postfix) with ESMTPSA id 34576628068E; Thu, 22 Mar 2018 13:30:55 +0100 (CET) From: Milian Wolff To: elfutils-devel@sourceware.org Cc: Mark Wielaard Subject: Re: How to associate Elf with Dwfl_Module returned by dwfl_report_module Date: Thu, 22 Mar 2018 12:30:00 -0000 Message-ID: <1959812.uGpsuYQ9sd@agathebauer> In-Reply-To: <20180321213107.GK6269@wildebeest.org> References: <3517953.ztkfjMdy38@agathebauer> <1581387.j5xz9UsgaX@agathebauer> <20180321213107.GK6269@wildebeest.org> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart1934927.QpdkSNWYJx"; micalg="pgp-sha256"; protocol="application/pgp-signature" X-IsSubscribed: yes X-SW-Source: 2018-q1/txt/msg00100.txt.bz2 --nextPart1934927.QpdkSNWYJx Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="iso-8859-1" Content-length: 2572 On Mittwoch, 21. M=E4rz 2018 22:31:07 CET Mark Wielaard wrote: > On Wed, Mar 21, 2018 at 03:23:51PM +0100, Milian Wolff wrote: > > Here's one way to investigate where perf and dwfl disagree on the file > > mappings: > >=20 > > diff --git a/tools/perf/util/unwind-libdw.c > > b/tools/perf/util/unwind-libdw.c index 7bdd239c795c..739c68b73772 100644 > > --- a/tools/perf/util/unwind-libdw.c > > +++ b/tools/perf/util/unwind-libdw.c > > @@ -48,11 +48,17 @@ static int __report_module(struct addr_location *al, > > u64 ip, > >=20 > > mod =3D 0; > >=20=20=09 > > } > >=20 > > - if (!mod) > > + if (!mod) { > > + Dwarf_Addr s, e; > >=20 > > mod =3D dwfl_report_elf(ui->dwfl, dso->short_name, > >=20=20=09=09 > > (dso->symsrc_filename ? dso->symsrc_filename : dso- > > > > > >long_name), -1, al->map->start, > > > > > false); > >=20 > > + dwfl_module_info(mod, NULL, &s, &e, NULL, NULL, NULL, NULL); > > + if (al->map->start !=3D s || al->map->end !=3D e) > > + pr_warning("MEH: %s | mmap: %zx %zx | dwfl: %zx %zx\n", dso- > >=20 > > >short_name, al->map->start, al->map->end, s, e); > >=20 > > + } > > + > >=20 > > return mod && dwfl_addrmodule(ui->dwfl, ip) =3D=3D mod ? 0 : -1; > >=20=20 > > } > >=20 > > On one of my perf.data files with many broken backtraces this gives me: > >=20 > > MEH: heaptrack_print | mmap: 56166e9d4000 56166ea39000 | dwfl: > > 56166e9d4000 > > 56166ea38880 > > MEH: ld-2.26.so | mmap: 7fd0afc6c000 7fd0afe93000 | dwfl: 7fd0afc6c000 > > 7fd0afe920f8 > > MEH: libc-2.26.so | mmap: 7fd0ae16a000 7fd0ae521000 | dwfl: 7fd0ae16a000 > > 7fd0ae5208f0 > > MEH: libstdc++.so.6.0.24 | mmap: 7fd0aea84000 7fd0aee0b000 | dwfl: > > 7fd0aea84000 7fd0aee0a640 > > MEH: libzstd.so.1.3.3 | mmap: 7fd0aee0b000 7fd0af087000 | dwfl: > > 7fd0aee0b000 7fd0af086030 > >=20 > > Interestingly, here the mmap events observed by perf are actually always > > *larger* than what dwfl sees... >=20 > I think that is simply the end address being extended to the next page. > Where the page size seems to be 4K (0x1000). I assume if you look at > the actual LOAD segment sizes of the files (eu-readelf -l) they match > with what dwfl reports, and if it extends to the nearest 4k page it > matches whatp mmap reports. Yes, I agree - the above does not explain the issues I am seeing. It is mos= t=20 probably just noise and can be ignored. I'll try to dig deeper to figure out what is going on and then come back he= re.=20 For now, it seems like using dwfl_report_elf is fine. Cheers --=20 Milian Wolff mail@milianw.de http://milianw.de= --nextPart1934927.QpdkSNWYJx Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part. Content-Transfer-Encoding: 7Bit Content-length: 833 -----BEGIN PGP SIGNATURE----- iQIzBAABCAAdFiEEezawi1aUvUGg3A1+8zYW/HGdOX8FAlqzof4ACgkQ8zYW/HGd OX+T0BAAhzBcEBK1H9ce8yONUG+aYvnB2q/0dZgyNgdLxy3qILPL+2sdlu/uuNQz PyAy6XkFsHAkuP2xgS0PClbptxo/i96cxxm4cp2RmK9EPo8o0UIqQ0J3pv9kwcvy H8uMewK1YKpv7D7A0n2zMwymekM9b83o8vIA4mY+wJVljxQuDWdGh4vvALkhLxvR moCPmK31y5BLCIVyCGghqWCKLiTgMx7/wcG6vkjLDPfpTtCxSH6232QFpeeIV6xk DS7mt5KJop480hlSLwShTSTOQFpMqqoM68/pguLuieRZruur3zZELB38pXBLm389 ct+LckiTt9L8K5B0bgJ7CI/UO9w/sEPZ7nOnwfJOr2XxMiohNU7cyLi4HVr7aJUU kbIqVv72djUx1YS5ogKSA8bQhHlwV6GbrOF+Y1A28QQSbjj5+nXubTLxirH298sV SgFSrtNlnnkk/3p1cE5whQ/fMEIW79+opNvAGfI68bvIpbWnelKC9GWYa2+7dtXg 8UYE0YfL+iaRV7LLbH7vB2h8BOMPl7/KgsaeLCo3bQzvEr5UWyZIckX0rHi0G8ip DALsAcneAMy0mm2zNxEWxcELGZwtWI98dKJmTMm8kiZdGvqDqRaZmR7man224k7k DtxXyMWNEhRtrP9geTliWijIs11JheLRYOGvE9ZUveKZpf5Aaqw= =nkQD -----END PGP SIGNATURE----- --nextPart1934927.QpdkSNWYJx--