jankratochvil added a comment. 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 https://reviews.llvm.org/D32167 _______________________________________________ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
