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

Jan Kratochvil via Phabricator via lldb-commits lldb-commits at lists.llvm.org
Sun Mar 4 08:04:33 PST 2018


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





More information about the lldb-commits mailing list