[Lldb-commits] [PATCH] D32167: Add support for type units (.debug_types) to LLDB in a way that is compatible with DWARF 5

[Davide Italiano via Phabricator via lldb-commits]

davide added a comment.

In https://reviews.llvm.org/D32167#1026762, @jankratochvil wrote:

> In https://reviews.llvm.org/D32167#1024546, @labath wrote:
>
> > I personally don't think having a new debug info flavour is a good idea. Tests written specifically to test this functionality will be easier to maintain and debug when they break. And keeping adding new flavours for every compiler option is not a viable long term strategy.
>
>
> Here I disagree, from GDB testsuite experience I find more wider testing always better as it will better catch bugs even in unrelated new functionalities being implemented in the future. One can never guess all the combinations in advance - if one could then one needs no regression testing at all. There are more than enough CPU cycles available for testing.  I find rather a serious problem racy==unreliable test results which waste human efforts investigating the results and with more parallel testing (make -j) and virtualized infrastructure the racy results happen even more often.  As an example one racy testcase I idenitifed is:
>
>   packages/Python/lldbsuite/test/functionalities/signal/handle-segv/TestHandleSegv.py
>   line 33: AssertionError: 4 != 5 (eStateLaunching != eStateStopped)
>   
>
> I think at least these test are racy:
>
>   BreakpointAfterJoinTestCase-test
>    CreateDuringStepTestCase-test_step_inst_with
>    HandleSegvTestCase-test_inferior_handle_sigsegv
>    ReturnValueTestCase-test_vector_values
>    TestTargetSymbolsBuildidSymlink-test_target_symbols_buildid
>    ThreadSpecificBreakPlusConditionTestCase-test_python
>    ThreadSpecificBreakTestCase-test_python
>    ThreadStateTestCase-test_process_interrupt
>   


I'm not necessarily convinced having another column in the matrix is something that can substitute targeted testing.
If you're talking about something complementary, I think we might consider it, as a follow up.
Also, thanks for bringing the problem of the racy tests up. Adding another row in the matrix increases the chances of test failures. I think we might consider addressing the unreliability before making such a big change. Do you have a way of reproducing? [or even better, investigating]

Our bots have been green for a while (we tried to investigate known issues http://lab.llvm.org:8080/green/view/LLDB/) but we can only address what we know :)


https://reviews.llvm.org/D32167