[Lldb-commits] [PATCH] D40475: DWZ 12/12: DWZ test mode

[Pavel Labath via lldb-commits]

On 30 November 2017 at 20:17, Jan Kratochvil via Phabricator
<reviews at 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).