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 _______________________________________________ lldb-commits mailing list lldb-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits
