From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 112992 invoked by alias); 21 Mar 2018 21:31:12 -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 112975 invoked by uid 89); 21 Mar 2018 21:31:11 -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=-26.9 required=5.0 tests=BAYES_00,GIT_PATCH_0,GIT_PATCH_1,GIT_PATCH_2,GIT_PATCH_3,SPF_PASS autolearn=ham version=3.3.2 spammy= X-Spam-Status: No, score=-26.9 required=5.0 tests=BAYES_00,GIT_PATCH_0,GIT_PATCH_1,GIT_PATCH_2,GIT_PATCH_3,SPF_PASS 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: gnu.wildebeest.org Received: from wildebeest.demon.nl (HELO gnu.wildebeest.org) (212.238.236.112) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 21 Mar 2018 21:31:10 +0000 Received: from librem.wildebeest.org (deer0x01.wildebeest.org [172.31.17.131]) (using TLSv1.2 with cipher ADH-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by gnu.wildebeest.org (Postfix) with ESMTPSA id 194833014707; Wed, 21 Mar 2018 22:31:08 +0100 (CET) Received: by librem.wildebeest.org (Postfix, from userid 1000) id D6540142C6E; Wed, 21 Mar 2018 22:31:07 +0100 (CET) Date: Wed, 21 Mar 2018 21:31:00 -0000 From: Mark Wielaard To: Milian Wolff Cc: elfutils-devel@sourceware.org Subject: Re: How to associate Elf with Dwfl_Module returned by dwfl_report_module Message-ID: <20180321213107.GK6269@wildebeest.org> References: <3517953.ztkfjMdy38@agathebauer> <20180320220549.GD6269@wildebeest.org> <1946852.ajpeOdNFGP@agathebauer> <1581387.j5xz9UsgaX@agathebauer> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1581387.j5xz9UsgaX@agathebauer> User-Agent: Mutt/1.9.3 (2018-01-21) X-Spam-Flag: NO X-IsSubscribed: yes X-SW-Source: 2018-q1/txt/msg00097.txt.bz2 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: > > 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, > mod = 0; > } > > - if (!mod) > + if (!mod) { > + Dwarf_Addr s, e; > mod = dwfl_report_elf(ui->dwfl, dso->short_name, > (dso->symsrc_filename ? dso->symsrc_filename : dso- > >long_name), -1, al->map->start, > false); > > + dwfl_module_info(mod, NULL, &s, &e, NULL, NULL, NULL, NULL); > + if (al->map->start != s || al->map->end != e) > + pr_warning("MEH: %s | mmap: %zx %zx | dwfl: %zx %zx\n", dso- > >short_name, al->map->start, al->map->end, s, e); > + } > + > return mod && dwfl_addrmodule(ui->dwfl, ip) == mod ? 0 : -1; > } > > On one of my perf.data files with many broken backtraces this gives me: > > 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 > > Interestingly, here the mmap events observed by perf are actually always > *larger* than what dwfl sees... 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. Cheers, Mark