From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 94034 invoked by alias); 22 Mar 2018 12:29:58 -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 94023 invoked by uid 89); 22 Mar 2018 12:29: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=-2.8 required=5.0 tests=AWL,BAYES_00,KAM_LAZY_DOMAIN_SECURITY,KAM_SHORT,RCVD_IN_DNSWL_LOW autolearn=no version=3.3.2 spammy= X-Spam-Status: No, score=-2.8 required=5.0 tests=AWL,BAYES_00,KAM_LAZY_DOMAIN_SECURITY,KAM_SHORT,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; Thu, 22 Mar 2018 12:29:56 +0000 Received: from agathebauer.localnet (ip5f5bf42a.dynamic.kabel-deutschland.de [95.91.244.42]) by dd17628.kasserver.com (Postfix) with ESMTPSA id C09ED628068E; Thu, 22 Mar 2018 13:29:53 +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:29:00 -0000 Message-ID: <14775352.FygvDYPznE@agathebauer> In-Reply-To: <20180321212113.GJ6269@wildebeest.org> References: <3517953.ztkfjMdy38@agathebauer> <1946852.ajpeOdNFGP@agathebauer> <20180321212113.GJ6269@wildebeest.org> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart3088011.mDmcqtrzC5"; micalg="pgp-sha256"; protocol="application/pgp-signature" X-IsSubscribed: yes X-SW-Source: 2018-q1/txt/msg00099.txt.bz2 --nextPart3088011.mDmcqtrzC5 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="iso-8859-1" Content-length: 3688 On Mittwoch, 21. M=E4rz 2018 22:21:13 CET Mark Wielaard wrote: > Hi Milian, >=20 > On Wed, Mar 21, 2018 at 02:01:41PM +0100, Milian Wolff wrote: > > Here's the code for the perf tools: > >=20 > > https://git.kernel.org/pub/scm/linux/kernel/git/acme/linux.git/tree/too= ls/ > > perf/util/unwind-libdw.c?h=3Dperf/core#n52 > >=20 > > Here's the code for the perfparser: > >=20 > > http://code.qt.io/cgit/qt-creator/perfparser.git/tree/app/ > > perfsymboltable.cpp#n479 > >=20 > > Let's concentrate on perf for now, but perfparser has similar logic: > >=20 > > We parse the mmap events in the perf.data file and store that informati= on. > > Note that the perf.data file does not contain events for munmap calls. > > Then > > while unwinding the callstack of a perf sample, we lookup the most rece= nt > > mmap event for every given instruction pointer address, and ensure that > > the corresponding ELF was registered with libdw. >=20 > So, modules are never deregistered? > In that case, that might explain the issue. No, they are deregistered - that is not the issue. Perf actually starts wit= h a=20 clean dwfl on every sample and registers whatever modules are relevant for = the=20 given sample. perfparser tries to be a bit smarter and caches more, but als= o=20 has code to deregister if something goes amiss. > But I see there is a check if there is already something at the address. > The interface to "remove" a module might not be immediately clear. > The idea is that if modules need to be remove you'll call > dwfl_report_begin, possibly dwfl_report_elf for any new module and then > dwfl_report_end has a callback that gets all old modules and decides > whether to re-report them, or they'll get removed. You might want to > experiment with doing that and not re-report any module that overlaps > with the new module. (See the libdwfl.h documentation for a hopefully > clearer description.) >=20 > > > Specifically are you using false for the add_p_vaddr argument? > >=20 > > Yes, we are. > >=20 > > > And could you provide some example where the reported address is > > > wrong/different from the start address of the Dwfl_Module? > >=20 > > I don't think it's the start address that is wrong, rather it's the end > > address. But it's hard for me to come up with a small selfcontained > > example at this stage. I am regularly seeing broken backtraces for > > samples where I have the gut feeling that missing reported ELFs are to > > blame. But we report everything, except for scenarios where the mmap > > events seemingly overlap. This overlapping is, as far as I can see, > > actually a side effect of remapping taking place in the dynamic linker > > (i.e. a single dlopen/dynamic linked library can yield multiple mmap > > events). One way or another, we end up with a situation where we cannot > > report an ELF to dwfl due to two issues: > >=20 > > a) either ELF tells us we are overlapping some module and just stops wh= ich > > is bad, since we would actually much prefer the newly reported ELF to > > take precedence > >=20 > > b) we find an mmap event that with a non-zero pgoff, and have no clue h= ow > > to call dwfl_report_elf and just give up. > >=20 > > In both cases, I was hopeing for dwfl_report_module to help since it > > seemingly allows me to exactly recreate the mapping that was traced > > originally. > If you could add some logging and post that plus the eu-readelf -l > output of the ELF file, that might help track down what is really going > on. Yes, I will try to find the time to write a more elaborate reproducer for t= his=20 issue, to better figure out what is going on here. Bye --=20 Milian Wolff mail@milianw.de http://milianw.de= --nextPart3088011.mDmcqtrzC5 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/HGdOX8FAlqzobwACgkQ8zYW/HGd OX+p3A//e/b04CtULVwUjayg7ZXhasEvIGdD8EDA8cc7U4iCy6FgsciPFbXMHbtU 2NFSgdgwQ/V5pMnT2nSwYKpc7awgIz1opZI87NvAPrH1NFe8CwHnhsjqHRJIT0gH MF2gN6IGPUvsVBpwFir1rB30fwXGLzqqipmUf4CI74ZgUAmAPbG8lFtDv6EWeW6s zmK7k6KZDhw2wiH/WuKy/Hn7f+0tmm1nM1Pw8F84a/MnsqfgIPis4XAgOTyzpRFP RP49DE+tZoM3IfRGAQP7SfFAtT9xONqcjOXnjg55DxXCjIDJ0iHgUu3NVmuDVW6J gIfFwrNbvAxyQvT8k3ohJp2prXtbRtuAV6Q5qio5UdRxo4rmcKgM/vi/+47kjOs1 cktPiHAN+9M1pY3t7+Nacnuyt2q+qULLnR/2E8rt8rkYafUK+yYr3NfByzTFvo8y oZpIMookEKAQ1urBbjcjtCS9UvdUjVqqMqO31glKZ3EJ6lh6Vh4JMVlzcJfEhtS3 Vza8pAqgU5nqwFT7jtrJZwUUy4Tv3Sza8EO71qAAy9qGQx5T4g6Zu1FZ1qP3Yvrz BzLmN1L/s6F1fG5QRGEHNA0WWLpCX65rFGU1PjhnJEHc8Ati4XjoG8EnjdtALFbN jt7RqeAubXoJ39tR0GDYhut5i9fg0aRQqkHrTXZDyqZ4KmMzrnU= =O89v -----END PGP SIGNATURE----- --nextPart3088011.mDmcqtrzC5--