[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