From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 20223 invoked by alias); 6 May 2017 11:30:44 -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 19857 invoked by uid 89); 6 May 2017 11:30:26 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Checked: by ClamAV 0.99.2 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=knowingly, H*F:U*mail, our 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; Sat, 06 May 2017 11:30:24 +0000 Received: from agathebauer.localnet (ip5f5bd54a.dynamic.kabel-deutschland.de [95.91.213.74]) by dd17628.kasserver.com (Postfix) with ESMTPSA id D0A496280245; Sat, 6 May 2017 13:30:23 +0200 (CEST) From: Milian Wolff To: Mark Wielaard Cc: elfutils-devel@sourceware.org Subject: Re: dwfl_module_addrdie fails for binaries built with clang++ Date: Mon, 08 May 2017 10:42:00 -0000 Message-ID: <1944705.9f9Bnx5Tt5@agathebauer> In-Reply-To: <1493989608.31726.307.camel@klomp.org> References: <13834170.MbzIeY4TI5@milian-kdab2> <1493989608.31726.307.camel@klomp.org> MIME-Version: 1.0 Content-Type: multipart/signed; boundary="nextPart2661535.Mb3IVkLSJK"; micalg="pgp-sha1"; protocol="application/pgp-signature" X-IsSubscribed: yes X-SW-Source: 2017-q2/txt/msg00198.txt.bz2 --nextPart2661535.Mb3IVkLSJK Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Content-length: 3197 On Freitag, 5. Mai 2017 15:06:48 CEST Mark Wielaard wrote: > Hi Milian, > > On Thu, 2017-05-04 at 18:05 +0200, Milian Wolff wrote: > > I noticed that elfutils fails to handle clang binaries when we want to > > find a DIE for a certain address. I.e. dwfl_module_addrdie returns > > nullptr, and eu- addr2line fails to resolve inlined frames. > > > > To reproduce this: > >[...] > > > > This also affects us in our perfparser. Not being able to find a cudie > > means not finding inlined frames nor file/line mappings, which is quite a > > set-back. > > > > I have noticed that backward-cpp contains a (partially) work-around for > > this: > > > > https://github.com/bombela/backward-cpp/blob/master/backward.hpp#L1216 > > O urgh how utterly broken (not backward-cpp, but the bogus DWARF clang > generates). As that comment says: > > // Sadly clang does not generate the section .debug_aranges, > thus > // dwfl_module_addrdie will fail early. Clang doesn't either set > // the lowpc/highpc/range info for every compilation unit. > // > // So in order to save the world: > // for every compilation unit, we will iterate over every single > // DIEs. Normally functions should have a lowpc/highpc/range, which > // we will use to infer the compilation unit. > > // note that this is probably badly inefficient. > > And indeed having to scan through every CU to find a matching function > DIE is badly inefficient :{ But this code comment is relatively old. Are we sure it's really still the case? > > Is this the right approach and also what the non-eu addr2line does? If so, > > can that be added upstream too, such that dwfl_module_addrdie can be > > relied on? > > > > I've seen it on clang 3.6, 4 and 5. Neither passing -g3 nor > > -gdwarf-aranges > > helps. > > Thanks for reporting this. I think this might be the same issue seen > here: https://sourceware.org/bugzilla/show_bug.cgi?id=21247 > ... or at least it seems related. The function/address not found in that > case also comes from a CU generated by clang. It does have a lowpc and > ranges, but the lowpc looks bogus (zero) and the ranges don't seem to > cover the function in question. So it seems even worse than your example > where there are no lowpc/ranges. We cannot even trust them if they are > there. Sigh. So the situation is different from the comment in backward-cpp... > I have to think about how to handle this. We clearly need something that > just ignores the lowpc/highpc/ranges on CUs and parses every CU till the > function/address DIE is found to know which CU and line_table to use. > But that is so inefficient that I don't want to do that by default. So, if this is really that bad - what are the binutils doing - does anyone know? Also, if it's really against all your expectations, shouldn't we report this upstream at clang and ask for input there? I can't believe they knowingly break their generated code in such a way. Rather, I believe it's either done unknowingly, or there is some alternative way to interpret the data that we are not aware of? Cheers -- Milian Wolff mail@milianw.de http://milianw.de --nextPart2661535.Mb3IVkLSJK Content-Type: application/pgp-signature; name="signature.asc" Content-Description: This is a digitally signed message part. Content-Transfer-Encoding: 7Bit Content-length: 195 -----BEGIN PGP SIGNATURE----- iF0EABECAB0WIQQ9hWiGkJfGXJj40nYMDrISzR0TkwUCWQ2zzgAKCRAMDrISzR0T kw8JAJ9gT269tBKd1CAeFxVLP0UIq+egDgCgxBkro86zxrZXClqg+WlMJLR6Du4= =4FDf -----END PGP SIGNATURE----- --nextPart2661535.Mb3IVkLSJK--