From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 97485 invoked by alias); 15 Oct 2018 20:39:00 -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 97459 invoked by uid 89); 15 Oct 2018 20:38:59 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Checked: by ClamAV 0.100.1 on sourceware.org X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.6 required=5.0 tests=BAYES_00,KAM_LAZY_DOMAIN_SECURITY,RCVD_IN_DNSWL_LOW autolearn=no version=3.3.2 spammy=apologies, H*F:U*mail X-Spam-Status: No, score=-1.6 required=5.0 tests=BAYES_00,KAM_LAZY_DOMAIN_SECURITY,RCVD_IN_DNSWL_LOW autolearn=no 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; Mon, 15 Oct 2018 20:38:57 +0000 Received: from agathebauer.localnet (p54A1B429.dip0.t-ipconnect.de [84.161.180.41]) by dd17628.kasserver.com (Postfix) with ESMTPSA id 6091962806BB; Mon, 15 Oct 2018 22:38:54 +0200 (CEST) From: Milian Wolff To: elfutils-devel@sourceware.org Cc: Mark Wielaard , Ulf Hermann , Christoph Sterz Subject: Re: Handling pgoff in perf elf mmap/mmap2 elf info Date: Mon, 15 Oct 2018 20:39:00 -0000 Message-ID: <4862287.LsxLGO1v19@agathebauer> In-Reply-To: <3480068.6G4le2ijG6@agathebauer> References: <20181011173707.GA8552@wildebeest.org> <3480068.6G4le2ijG6@agathebauer> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart2180019.4yBupO79rK"; micalg="pgp-sha256"; protocol="application/pgp-signature" X-IsSubscribed: yes X-SW-Source: 2018-q4/txt/msg00034.txt.bz2 --nextPart2180019.4yBupO79rK Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Content-length: 3966 On Donnerstag, 11. Oktober 2018 20:14:43 CEST Milian Wolff wrote: > On Donnerstag, 11. Oktober 2018 19:37:07 CEST Mark Wielaard wrote: > > Hi, > > > > My apologies for not having looked deeper at this. > > It is a bit tricky and I just didnt have enough time to > > really sit down and think it all through yet. > > > > On Thu, Oct 11, 2018 at 05:02:18PM +0000, Ulf Hermann wrote: > > > is there any pattern in how the loader maps the ELF sections into > > > memory? What sections does it actually map and which of those do we need > > > for unwinding? > > > > Yes, it would be helpful to have some examples of mmap events plus > > the associated segment header (eu-readelf -l) of the ELF file. > > > > Note that the kernel and dynamic loader will use the (PT_LOAD) segments, > > not the sections, to map things into memory. Each segment might contain > > multiple sections. > > > > libdwfl then tries to associate the correct sections (and address bias) > > with how the ELF file was mapped into memory. > > > > > I hope that only one of those MMAPs per ELF is actually meaningful and > > > we can simply add that one's pgoff as an extra member to Dwfl_Module and > > > use it whenever we poke the underlying file. > > > > One "trick" might be to just substract the pgoff from the load address. > > And so report as if the ELF file was being mapped from the start. This > > isn't really correct, but it might be interesting to see if that makes > > libdwfl able to just associate the whole ELF file with the correct > > address map. > > I'll try to come up with some minimal code examples we can use to test all > of this. But from what I remember, neither of the above suggestions will be > sufficient as we can still run into overlapping module errors from elfutils > when we always load everything. I.e. I believe we've seen mappings that > eventually become partially obsoleted by a future mmap event. At that > point, we somehow need to be able to only map parts of a file, not all of > it. So just subtracting or honoring pgoff is not enough, I believe we also > need to be able to explicitly say how much of a file to map. > > But to make this discussion easier to follow for others, I'll create some > standalone cpp code that takes a `perf script --show-mmap-events | grep > PERF_RECORD_MMAP` input file and then runs this through elfutils API to > reproduce the issues we are facing. > > I'll get back to you all once this is done. Hey all, here's one example of mmap events recorded by perf: 0x7fac5ec0b000 to 0x7fac5ed9a000, len = 0x18f000, offset = 0 r--p /usr/lib/libstdc++.so.6.0.25 0x7fac5ec94000 to 0x7fac5ed8a000, len = 0xf6000, offset = 0x89000 ---p /usr/lib/libstdc++.so.6.0.25 0x7fac5ec94000 to 0x7fac5ed4c000, len = 0xb8000, offset = 0x89000 r-xp /usr/lib/libstdc++.so.6.0.25 0x7fac5ed4c000 to 0x7fac5ed89000, len = 0x3d000, offset = 0x141000 r--p /usr/lib/libstdc++.so.6.0.25 0x7fac5ed8a000 to 0x7fac5ed97000, len = 0xd000, offset = 0x17e000 rw-p /usr/lib/libstdc++.so.6.0.25 this is noteworthy in multiple ways: - the first mapping we receive is for pgoff = 0 for the full file size aligned to the page boundary - the first mapping isn't executable yet - the last mappings have a huge offset which actually lies beyond the initially mmaped region?! And to make things worse, when we report the file at address 0x7fac5ec0b000 via dwfl, we get: reported module /usr/lib/libstdc++.so.6.0.25 expected: 0x7fac5ec0b000 to 0x7fac5ed9a000 (0x18f000) actual: 0x7fac5ec0b000 to 0x7fac5ed99640 (0x18e640) So now dwfl won't ever be able to map any addresses into this module when they come after 0x7fac5ed99640, but the mmap events above seem to indicate that this could be possible? I'll now upload my code to enable you all to play around with this yourself. Bye -- Milian Wolff mail@milianw.de http://milianw.de --nextPart2180019.4yBupO79rK 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/HGdOX8FAlvE+t0ACgkQ8zYW/HGd OX+adRAAj8E00m8p/qchVRTEtKqpzT6M6ADknaCxQh5QR+oBbTU3NxEMNZCwPp8C h7gN3MIB2Jcr6Zpigj3Vv7J9ZJGnuNUz9uT0jfNrAXkIVFyX2+Wz7KH2iQ4DDaiL mdsoPAUA0Xq6OwtSIp7ETP60J/XJaAZmfRyHxoo5vJys6NkXaOON+cP+inBE4hQ3 JFu/To87abBsVrMJ/u8Z5BUdzMQHgbIweWN7OfyVR/g0Gz3Xd74L5w/VCCEpIoa4 U97wnRyzo7qlmEb0B87uSIKzCFp2DTePrI9BCS4Zs9BgoNS6fJfs51e87rHQqgHj F/NlnjVHFJa0mkfdTiOgWeaTcR2gp7t4pOa7ZSHT+ElmbelqZ7ddn0K6SowxMoIY iRbOVVUAILT8hEnyspGW/3gGXmF/I+saXVMqak6rvsihKNkTOSkL3xCTUabjkTxl zutqhSuyqRfK57zkn43hAhdLa3BEEAxfVpTm0urkdPe6sZl2HsouPork4cSKYPK1 bne6JGW1jmepdk2EIW478YXgeIkewvXzlcmuwpdRYETw+9VhC243Yxy9Zxyqb94Y dC5FiiqGXBrnqCe7wEMAjVjK4EAPlMD/hO5noGBpJQ/zE6+5UWn1hA2uhcd/m7Vd I2nLJMQZPubDPSFt6YUDn0t9/rEwRn1njVZQecgTy/HhHVyNXWU= =Ff7j -----END PGP SIGNATURE----- --nextPart2180019.4yBupO79rK--