On 30 November 2017 at 20:17, Jan Kratochvil via Phabricator <revi...@reviews.llvm.org> wrote: > jankratochvil added a comment. > > In https://reviews.llvm.org/D40475#940462, @labath wrote: > >> It looks like it could be a fun project to reimplement `dwz` on top of llvm >> dwarf library, but I understand that would be a considerable detour for you. > > > I think it would be best to drop DWZ, IIRC its gain is not much bigger than > `-fdebug-types-section` and it is incompatible with some 3rd party debug info > tools as DWZ did not really became a standard. I just want to make LLDB > compatible with it. > >> How many tests are we talking about here? Could you list them here? > > These tests ERROR due to `dwz: a.out.debug.dwz: .debug_info section not > present`: > > > functionalities/breakpoint/breakpoint_ignore_count/TestBreakpointIgnoreCount.py > > functionalities/data-formatter/data-formatter-ptr-to-array/TestPtrToArrayFormatting.py > functionalities/data-formatter/ptr_ref_typedef/TestPtrRef2Typedef.py > functionalities/data-formatter/typedef_array/TestTypedefArray.py > functionalities/frame_var_scope/TestFrameVariableScope.py > functionalities/signal/TestSendSignal.py > lang/cpp/bool/TestCPPBool.py > lang/cpp/frame-var-anon-unions/TestFrameVariableAnonymousUnions.py > lang/cpp/lambdas/TestLambdas.py > lang/cpp/nsimport/TestCppNsImport.py > linux/builtin_trap/TestBuiltinTrap.py > python_api/rdar-12481949/Test-rdar-12481949.py > sample_test/TestSampleInlineTest.py
That's strange, I definitely see .debug_info sections in these files. It looks like dwz is just getting confused here. > > > >> If these really don't produce any debug info, then we can probably just mark >> them as `@no_debug_info_testcase` > > I do not see this keyword in the tree. Sorry, it's @no_debug_info_test for a specific test method and NO_DEBUG_INFO_TESTCASE = True for the whole class. > >> Looking at the results, they don't seem that bad, really. Most of the >> failures are in data formatters -- I think a well-placed >> `-fno-limit-debug-info` would get those working. The other category is >> something in the system library confusing the test (e.g. can't find >> `environ` or an extra global variable `c`). I think we could get those >> resolved fairly quickly. >> >> BTW, is this on current master? I was hoping that some of these (such as >> TestTopLevelExpressions) would be resolved already. > > No, it was from 26th. I have refreshed the files with today's GIT hash > `6513119854292f1992c95073e99d55bf88456adb` = SVN `319402`. 26th was fresh enough. I'll take a look at what's going on here. > >> It would also be useful to figure out why does it hang, as it will probably >> affect your users as well. :) > > I expect because LLDB does not have any Linux DWARF index support, it has > only some Apple OSX index support. GDB's `.debug_index` is not usable for > LLDB as it does not contain DIE offsets. I would like to implement DWARF-5 > `.debug_names` for it later. Well... missing dwarf index can make things slower, as we will have to index things ourselves, but it should not make us hang. (That's not say .debug_index support would not be a great feature to have). _______________________________________________ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
