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 m...@milianw.de http://milianw.de
signature.asc
Description: This is a digitally signed message part.
