[lldb-dev] [llvm-dev] [lit] check-all hanging
Joel E. Denny via lldb-dev
lldb-dev at lists.llvm.org
Tue Jan 8 13:54:53 PST 2019
On Mon, Jan 7, 2019 at 9:08 PM Joel E. Denny <jdenny.ornl at gmail.com> wrote:
> On Mon, Jan 7, 2019 at 11:39 AM Adrian Prantl <aprantl at apple.com> wrote:
>
>>
>>
>> On Jan 7, 2019, at 8:28 AM, Joel E. Denny via lldb-dev <
>> lldb-dev at lists.llvm.org> wrote:
>>
>> On Mon, Jan 7, 2019 at 11:15 AM Davide Italiano <dccitaliano at gmail.com>
>> wrote:
>>
>>> On Sat, Jan 5, 2019 at 9:48 AM Joel E. Denny via lldb-dev
>>> <lldb-dev at lists.llvm.org> wrote:
>>> >
>>> > On Fri, Jan 4, 2019 at 11:39 AM Frédéric Riss <friss at apple.com> wrote:
>>> >>
>>> >>
>>> >>
>>> >> > On Jan 4, 2019, at 7:30 AM, Joel E. Denny <jdenny.ornl at gmail.com>
>>> wrote:
>>> >> >
>>> >> > On Thu, Jan 3, 2019 at 11:30 AM Frédéric Riss <friss at apple.com>
>>> wrote:
>>> >> > -llvm-dev + lldb-dev for the lldv test failures.
>>> >> >
>>> >> >> On Jan 3, 2019, at 7:33 AM, Joel E. Denny <jdenny.ornl at gmail.com>
>>> wrote:
>>> >> >>
>>> >> >> All,
>>> >> >>
>>> >> >> Thanks for the replies. Kuba: For LLDB, when were things expected
>>> to have improved? It's possible things improved for me at some point, but
>>> this isn't something I've found time to track carefully, and I still see
>>> problems.
>>> >> >>
>>> >> >> I ran check-all a couple of times last night at r350238, which I
>>> pulled yesterday. Here are the results:
>>> >> >>
>>> >> >> ```
>>> >> >> ********************
>>> >> >> Testing Time: 5043.24s
>>> >> >> ********************
>>> >> >> Unexpected Passing Tests (2):
>>> >> >> lldb-Suite :: functionalities/asan/TestMemoryHistory.py
>>> >> >> lldb-Suite :: functionalities/asan/TestReportData.py
>>> >> >>
>>> >> >> ********************
>>> >> >> Failing Tests (54):
>>> >> >> Clang :: CXX/modules-ts/basic/basic.link/p2/module.cpp
>>> >> >> Clang :: Modules/ExtDebugInfo.cpp
>>> >> >> Clang :: Modules/using-directive-redecl.cpp
>>> >> >> Clang :: Modules/using-directive.cpp
>>> >> >> Clang :: PCH/chain-late-anonymous-namespace.cpp
>>> >> >> Clang :: PCH/cxx-namespaces.cpp
>>> >> >> Clang :: PCH/namespaces.cpp
>>> >> >> LLDB :: ExecControl/StopHook/stop-hook-threads.test
>>> >> >> LeakSanitizer-AddressSanitizer-x86_64 :: TestCases/Linux/
>>> use_tls_dynamic.cc
>>> >> >> LeakSanitizer-Standalone-x86_64 :: TestCases/Linux/
>>> use_tls_dynamic.cc
>>> >> >> MemorySanitizer-X86_64 :: dtls_test.c
>>> >> >> MemorySanitizer-lld-X86_64 :: dtls_test.c
>>> >> >> lldb-Suite ::
>>> functionalities/register/register_command/TestRegisters.py
>>> >> >> lldb-Suite :: tools/lldb-server/TestGdbRemoteRegisterState.py
>>> >> >
>>> >> > It’s hard to diagnose dotest failures without the log.
>>> >> >
>>> >> > (My last reply to this was rejected by the list because I wasn't
>>> subscribed. Trying again.)
>>> >> >
>>> >> > I have no experience debugging lldb. Here's the lit output for the
>>> last fail (now at r350377), but let me know if you want something more:
>>> >> >
>>> >> > ```
>>> >> > FAIL: lldb-Suite :: tools/lldb-server/TestGdbRemoteRegisterState.py
>>> (59083 of 59736)
>>> >> > ******************** TEST 'lldb-Suite ::
>>> tools/lldb-server/TestGdbRemoteRegisterState.py' FAILED ********************
>>> >> > lldb version 8.0.0
>>> >> > LLDB library dir: /home/jdenny/ornl/llvm-mono-git-build/bin
>>> >> > LLDB import library dir: /home/jdenny/ornl/llvm-mono-git-build/bin
>>> >> > Libc++ tests will not be run because: Unable to find libc++
>>> installation
>>> >> > Skipping following debug info categories: ['dsym', 'gmodules']
>>> >> >
>>> >> > Session logs for test failures/errors/unexpected successes will go
>>> into directory '/home/jdenny/ornl/llvm-mono-git-build/lldb-test-traces'
>>> >> > Command invoked:
>>> /home/jdenny/ornl/llvm-mono-git/lldb/test/dotest.py -q --arch=x86_64 -s
>>> /home/jdenny/ornl/llvm-mono-git-build/lldb-test-traces --build-dir
>>> /home/jdenny/ornl/llvm-mono-git-build/lldb-test-build.noindex -S nm -u
>>> CXXFLAGS -u CFLAGS --executable
>>> /home/jdenny/ornl/llvm-mono-git-build/./bin/lldb --dsymutil
>>> /home/jdenny/ornl/llvm-mono-git-build/./bin/dsymutil --filecheck
>>> /home/jdenny/ornl/llvm-mono-git-build/./bin/FileCheck -C
>>> /home/jdenny/ornl/llvm-mono-git-build/./bin/clang --env
>>> ARCHIVER=/usr/bin/ar --env OBJCOPY=/usr/bin/objcopy
>>> /home/jdenny/ornl/llvm-mono-git/lldb/packages/Python/lldbsuite/test/tools/lldb-server
>>> -p TestGdbRemoteRegisterState.py
>>> >> > UNSUPPORTED: LLDB
>>> (/home/jdenny/ornl/llvm-mono-git-build/bin/clang-8-x86_64) ::
>>> test_grp_register_save_restore_works_no_suffix_debugserver
>>> (TestGdbRemoteRegisterState.TestGdbRemoteRegisterState) (debugserver tests)
>>> >> > FAIL: LLDB
>>> (/home/jdenny/ornl/llvm-mono-git-build/bin/clang-8-x86_64) ::
>>> test_grp_register_save_restore_works_no_suffix_llgs
>>> (TestGdbRemoteRegisterState.TestGdbRemoteRegisterState)
>>> >> > lldb-server exiting...
>>> >> > UNSUPPORTED: LLDB
>>> (/home/jdenny/ornl/llvm-mono-git-build/bin/clang-8-x86_64) ::
>>> test_grp_register_save_restore_works_with_suffix_debugserver
>>> (TestGdbRemoteRegisterState.TestGdbRemoteRegisterState) (debugserver tests)
>>> >> > FAIL: LLDB
>>> (/home/jdenny/ornl/llvm-mono-git-build/bin/clang-8-x86_64) ::
>>> test_grp_register_save_restore_works_with_suffix_llgs
>>> (TestGdbRemoteRegisterState.TestGdbRemoteRegisterState)
>>> >> > lldb-server exiting...
>>> >> >
>>> ======================================================================
>>> >> > FAIL: test_grp_register_save_restore_works_no_suffix_llgs
>>> (TestGdbRemoteRegisterState.TestGdbRemoteRegisterState)
>>> >> >
>>> ----------------------------------------------------------------------
>>> >> > Traceback (most recent call last):
>>> >> > File
>>> "/home/jdenny/ornl/llvm-mono-git/lldb/packages/Python/lldbsuite/test/decorators.py",
>>> line 144, in wrapper
>>> >> > func(*args, **kwargs)
>>> >> > File
>>> "/home/jdenny/ornl/llvm-mono-git/lldb/packages/Python/lldbsuite/test/tools/lldb-server/TestGdbRemoteRegisterState.py",
>>> line 137, in test_grp_register_save_restore_works_no_suffix_llgs
>>> >> > self.grp_register_save_restore_works(USE_THREAD_SUFFIX)
>>> >> > File
>>> "/home/jdenny/ornl/llvm-mono-git/lldb/packages/Python/lldbsuite/test/tools/lldb-server/TestGdbRemoteRegisterState.py",
>>> line 97, in grp_register_save_restore_works
>>> >> > context = self.expect_gdbremote_sequence()
>>> >> > File
>>> "/home/jdenny/ornl/llvm-mono-git/lldb/packages/Python/lldbsuite/test/tools/lldb-server/gdbremote_testcase.py",
>>> line 713, in expect_gdbremote_sequence
>>> >> > self.logger)
>>> >> > File
>>> "/home/jdenny/ornl/llvm-mono-git/lldb/packages/Python/lldbsuite/test/tools/lldb-server/lldbgdbserverutils.py",
>>> line 261, in expect_lldb_gdbserver_replay
>>> >> > asserter, content, context=context)
>>> >> > File
>>> "/home/jdenny/ornl/llvm-mono-git/lldb/packages/Python/lldbsuite/test/tools/lldb-server/lldbgdbserverutils.py",
>>> line 564, in assert_match
>>> >> > self._assert_exact_payload_match(asserter, actual_packet)
>>> >> > File
>>> "/home/jdenny/ornl/llvm-mono-git/lldb/packages/Python/lldbsuite/test/tools/lldb-server/lldbgdbserverutils.py",
>>> line 518, in _assert_exact_payload_match
>>> >> > assert_packets_equal(asserter, actual_packet,
>>> self.exact_payload)
>>> >> > File
>>> "/home/jdenny/ornl/llvm-mono-git/lldb/packages/Python/lldbsuite/test/tools/lldb-server/lldbgdbserverutils.py",
>>> line 159, in assert_packets_equal
>>> >> > asserter.assertEqual(actual_stripped, expected_stripped)
>>> >> > AssertionError: '$E77' != '$OK'
>>> >> > Config=x86_64-/home/jdenny/ornl/llvm-mono-git-build/bin/clang-8
>>> >> >
>>> ======================================================================
>>> >> > FAIL: test_grp_register_save_restore_works_with_suffix_llgs
>>> (TestGdbRemoteRegisterState.TestGdbRemoteRegisterState)
>>> >> >
>>> ----------------------------------------------------------------------
>>> >> > Traceback (most recent call last):
>>> >> > File
>>> "/home/jdenny/ornl/llvm-mono-git/lldb/packages/Python/lldbsuite/test/decorators.py",
>>> line 144, in wrapper
>>> >> > func(*args, **kwargs)
>>> >> > File
>>> "/home/jdenny/ornl/llvm-mono-git/lldb/packages/Python/lldbsuite/test/tools/lldb-server/TestGdbRemoteRegisterState.py",
>>> line 121, in test_grp_register_save_restore_works_with_suffix_llgs
>>> >> > self.grp_register_save_restore_works(USE_THREAD_SUFFIX)
>>> >> > File
>>> "/home/jdenny/ornl/llvm-mono-git/lldb/packages/Python/lldbsuite/test/tools/lldb-server/TestGdbRemoteRegisterState.py",
>>> line 97, in grp_register_save_restore_works
>>> >> > context = self.expect_gdbremote_sequence()
>>> >> > File
>>> "/home/jdenny/ornl/llvm-mono-git/lldb/packages/Python/lldbsuite/test/tools/lldb-server/gdbremote_testcase.py",
>>> line 713, in expect_gdbremote_sequence
>>> >> > self.logger)
>>> >> > File
>>> "/home/jdenny/ornl/llvm-mono-git/lldb/packages/Python/lldbsuite/test/tools/lldb-server/lldbgdbserverutils.py",
>>> line 261, in expect_lldb_gdbserver_replay
>>> >> > asserter, content, context=context)
>>> >> > File
>>> "/home/jdenny/ornl/llvm-mono-git/lldb/packages/Python/lldbsuite/test/tools/lldb-server/lldbgdbserverutils.py",
>>> line 564, in assert_match
>>> >> > self._assert_exact_payload_match(asserter, actual_packet)
>>> >> > File
>>> "/home/jdenny/ornl/llvm-mono-git/lldb/packages/Python/lldbsuite/test/tools/lldb-server/lldbgdbserverutils.py",
>>> line 518, in _assert_exact_payload_match
>>> >> > assert_packets_equal(asserter, actual_packet,
>>> self.exact_payload)
>>> >> > File
>>> "/home/jdenny/ornl/llvm-mono-git/lldb/packages/Python/lldbsuite/test/tools/lldb-server/lldbgdbserverutils.py",
>>> line 159, in assert_packets_equal
>>> >> > asserter.assertEqual(actual_stripped, expected_stripped)
>>> >> > AssertionError: '$E77' != '$OK'
>>> >> > Config=x86_64-/home/jdenny/ornl/llvm-mono-git-build/bin/clang-8
>>> >> >
>>> ----------------------------------------------------------------------
>>> >> > Ran 4 tests in 22.052s
>>> >>
>>> >> I’m not familiar with the lldb-server tests. Pavel might know what
>>> Error 77 is?
>>> >>
>>> >> > RESULT: FAILED (0 passes, 2 failures, 0 errors, 2 skipped, 0
>>> expected failures, 0 unexpected successes)
>>> >> >
>>> >> > ********************
>>> >> > ```
>>> >> >
>>> >> >
>>> >> >> lldb-Unit ::
>>> ScriptInterpreter/Python/./ScriptInterpreterPythonTests/PythonDataObjectsTest.TestBorrowedReferences
>>> >> >> lldb-Unit ::
>>> ScriptInterpreter/Python/./ScriptInterpreterPythonTests/PythonDataObjectsTest.TestDictionaryResolutionWithDot
>>> >> >> lldb-Unit ::
>>> ScriptInterpreter/Python/./ScriptInterpreterPythonTests/PythonDataObjectsTest.TestExtractingUInt64ThroughStructuredData
>>> >> >> lldb-Unit ::
>>> ScriptInterpreter/Python/./ScriptInterpreterPythonTests/PythonDataObjectsTest.TestGlobalNameResolutionNoDot
>>> >> >> lldb-Unit ::
>>> ScriptInterpreter/Python/./ScriptInterpreterPythonTests/PythonDataObjectsTest.TestGlobalNameResolutionWithDot
>>> >> >> lldb-Unit ::
>>> ScriptInterpreter/Python/./ScriptInterpreterPythonTests/PythonDataObjectsTest.TestInstanceNameResolutionNoDot
>>> >> >> lldb-Unit ::
>>> ScriptInterpreter/Python/./ScriptInterpreterPythonTests/PythonDataObjectsTest.TestModuleNameResolutionNoDot
>>> >> >> lldb-Unit ::
>>> ScriptInterpreter/Python/./ScriptInterpreterPythonTests/PythonDataObjectsTest.TestObjectAttributes
>>> >> >> lldb-Unit ::
>>> ScriptInterpreter/Python/./ScriptInterpreterPythonTests/PythonDataObjectsTest.TestOwnedReferences
>>> >> >> lldb-Unit ::
>>> ScriptInterpreter/Python/./ScriptInterpreterPythonTests/PythonDataObjectsTest.TestPythonByteArray
>>> >> >> lldb-Unit ::
>>> ScriptInterpreter/Python/./ScriptInterpreterPythonTests/PythonDataObjectsTest.TestPythonBytes
>>> >> >> lldb-Unit ::
>>> ScriptInterpreter/Python/./ScriptInterpreterPythonTests/PythonDataObjectsTest.TestPythonCallableCheck
>>> >> >> lldb-Unit ::
>>> ScriptInterpreter/Python/./ScriptInterpreterPythonTests/PythonDataObjectsTest.TestPythonCallableInvoke
>>> >> >> lldb-Unit ::
>>> ScriptInterpreter/Python/./ScriptInterpreterPythonTests/PythonDataObjectsTest.TestPythonDictionaryManipulation
>>> >> >> lldb-Unit ::
>>> ScriptInterpreter/Python/./ScriptInterpreterPythonTests/PythonDataObjectsTest.TestPythonDictionaryToStructuredDictionary
>>> >> >> lldb-Unit ::
>>> ScriptInterpreter/Python/./ScriptInterpreterPythonTests/PythonDataObjectsTest.TestPythonDictionaryValueEquality
>>> >> >> lldb-Unit ::
>>> ScriptInterpreter/Python/./ScriptInterpreterPythonTests/PythonDataObjectsTest.TestPythonFile
>>> >> >> lldb-Unit ::
>>> ScriptInterpreter/Python/./ScriptInterpreterPythonTests/PythonDataObjectsTest.TestPythonInteger
>>> >> >> lldb-Unit ::
>>> ScriptInterpreter/Python/./ScriptInterpreterPythonTests/PythonDataObjectsTest.TestPythonIntegerToStr
>>> >> >> lldb-Unit ::
>>> ScriptInterpreter/Python/./ScriptInterpreterPythonTests/PythonDataObjectsTest.TestPythonIntegerToStructuredInteger
>>> >> >> lldb-Unit ::
>>> ScriptInterpreter/Python/./ScriptInterpreterPythonTests/PythonDataObjectsTest.TestPythonListManipulation
>>> >> >> lldb-Unit ::
>>> ScriptInterpreter/Python/./ScriptInterpreterPythonTests/PythonDataObjectsTest.TestPythonListToStructuredList
>>> >> >> lldb-Unit ::
>>> ScriptInterpreter/Python/./ScriptInterpreterPythonTests/PythonDataObjectsTest.TestPythonListValueEquality
>>> >> >> lldb-Unit ::
>>> ScriptInterpreter/Python/./ScriptInterpreterPythonTests/PythonDataObjectsTest.TestPythonString
>>> >> >> lldb-Unit ::
>>> ScriptInterpreter/Python/./ScriptInterpreterPythonTests/PythonDataObjectsTest.TestPythonStringToStr
>>> >> >> lldb-Unit ::
>>> ScriptInterpreter/Python/./ScriptInterpreterPythonTests/PythonDataObjectsTest.TestPythonStringToStructuredString
>>> >> >> lldb-Unit ::
>>> ScriptInterpreter/Python/./ScriptInterpreterPythonTests/PythonDataObjectsTest.TestPythonTupleInitializerList
>>> >> >> lldb-Unit ::
>>> ScriptInterpreter/Python/./ScriptInterpreterPythonTests/PythonDataObjectsTest.TestPythonTupleInitializerList2
>>> >> >> lldb-Unit ::
>>> ScriptInterpreter/Python/./ScriptInterpreterPythonTests/PythonDataObjectsTest.TestPythonTupleSize
>>> >> >> lldb-Unit ::
>>> ScriptInterpreter/Python/./ScriptInterpreterPythonTests/PythonDataObjectsTest.TestPythonTupleToStructuredList
>>> >> >> lldb-Unit ::
>>> ScriptInterpreter/Python/./ScriptInterpreterPythonTests/PythonDataObjectsTest.TestPythonTupleValues
>>> >> >> lldb-Unit ::
>>> ScriptInterpreter/Python/./ScriptInterpreterPythonTests/PythonDataObjectsTest.TestResetting
>>> >> >> lldb-Unit ::
>>> ScriptInterpreter/Python/./ScriptInterpreterPythonTests/PythonDataObjectsTest.TestTypeNameResolutionNoDot
>>> >> >> lldb-Unit ::
>>> ScriptInterpreter/Python/./ScriptInterpreterPythonTests/PythonExceptionStateTest.TestAcquisitionSemantics
>>> >> >> lldb-Unit ::
>>> ScriptInterpreter/Python/./ScriptInterpreterPythonTests/PythonExceptionStateTest.TestAutoRestoreChanged
>>> >> >> lldb-Unit ::
>>> ScriptInterpreter/Python/./ScriptInterpreterPythonTests/PythonExceptionStateTest.TestAutoRestoreSemantics
>>> >> >> lldb-Unit ::
>>> ScriptInterpreter/Python/./ScriptInterpreterPythonTests/PythonExceptionStateTest.TestDiscardSemantics
>>> >> >> lldb-Unit ::
>>> ScriptInterpreter/Python/./ScriptInterpreterPythonTests/PythonExceptionStateTest.TestExceptionStateChecking
>>> >> >> lldb-Unit ::
>>> ScriptInterpreter/Python/./ScriptInterpreterPythonTests/PythonExceptionStateTest.TestManualRestoreSemantics
>>> >> >> lldb-Unit ::
>>> ScriptInterpreter/Python/./ScriptInterpreterPythonTests/PythonExceptionStateTest.TestResetSemantics
>>> >> >
>>> >> > Those unit test failures don’t ring a bell. Anyone’s seen this?
>>> Here too, knowing exactly the error message would help.
>>> >> >
>>> >> > Here's the lit output for the last one:
>>> >> >
>>> >> > ```
>>> >> > FAIL: lldb-Unit ::
>>> ScriptInterpreter/Python/./ScriptInterpreterPythonTests/PythonExceptionStateTest.TestResetSemantics
>>> (59324 of 59736)
>>> >> > ******************** TEST 'lldb-Unit ::
>>> ScriptInterpreter/Python/./ScriptInterpreterPythonTests/PythonExceptionStateTest.TestResetSemantics'
>>> FAILED ********************
>>> >> > Note: Google Test filter =
>>> PythonExceptionStateTest.TestResetSemantics
>>> >> > [==========] Running 1 test from 1 test case.
>>> >> > [----------] Global test environment set-up.
>>> >> > [----------] 1 test from PythonExceptionStateTest
>>> >> > [ RUN ] PythonExceptionStateTest.TestResetSemantics
>>> >> > ScriptInterpreterPythonTests:
>>> /home/jdenny/ornl/llvm-mono-git/llvm/include/llvm/Support/CommandLine.h:800:
>>> void llvm::cl::parser<llvm::ScheduleDAGInstrs
>>> *(*)(llvm::MachineSchedContext *)>::addLiteralOption(llvm::StringRef, const
>>> DT &, llvm::StringRef) [DataType = llvm::ScheduleDAGInstrs
>>> *(*)(llvm::MachineSchedContext *), DT = llvm::ScheduleDAGInstrs
>>> *(*)(llvm::MachineSchedContext *)]: Assertion `findOption(Name) ==
>>> Values.size() && "Option already exists!"' failed.
>>> >>
>>> >> That’s interesting. It seems like some clots are registered twice. As
>>> he backtrace shows that you have a libLLVMSupport.so, I could imagine this
>>> happening if the unittest was linking with both a static version and the
>>> dynamic version of the LLVM libraries, but that’s just a theory. I don’t
>>> know how good the build system is at dealing with a libraries build of
>>> LLVM, I wouldn’t be surprised if this is untested and thus broken.
>>> >
>>> >
>>> > I rebuilt without -DBUILD_SHARED_LIBS=true, and all the previous
>>> failing clang and lldb-Unit tests then passed (other test results did not
>>> change). My build size jumped from 33G to 136G. I didn't pay attention to
>>> the build time this time, but my past experience is that incremental builds
>>> can be many times slower without -DBUILD_SHARED_LIBS=true. This does not
>>> seem like a good solution for me.
>>> >
>>> > Joel
>>> >
>>>
>>> I think the number of people using BUILD_SHARED_LIBS=True is
>>> relatively limited, and there's no bot testing that configuration.
>>> Stefan is the resident build expert, so he might be able to comment.
>>>
>>
>> I see. So the large and slow builds are not a concern for most people?
>>
>>
>> Not sure if this is what you are seeing but: Because of the way debug
>> information is processed (or rather not processed by the linker), the link
>> times of debug builds on macOS are much faster than on Linux, so at least
>> for developers working on macOS this is not so much of an issue. On Linux
>> you might want to enable split dwarf support to get similar speedups even
>> for static links.
>>
>
> With BUILD_SHARED_LIBS=True, LLVM_USE_SPLIT_DWARF=True drops the build
> size from 33G to 24G.
> With BUILD_SHARED_LIBS=False, LLVM_USE_SPLIT_DWARF=True drops the build
> size from 136G to 71G.
>
> I also timed an incremental build after touching
> clang/lib/Sema/SemaOpenMP.cpp.
> With BUILD_SHARED_LIBS=True, LLVM_USE_SPLIT_DWARF=True drops the time from
> ~50s to ~31s.
> With BUILD_SHARED_LIBS=False, I only tried LLVM_USE_SPLIT_DWARF=True, and
> the time is ~3m53s.
>
> So, LLVM_USE_SPLIT_DWARF=True definitely helps. Thanks!
>
> However, I prefer to recompile and test frequently during development, so
> BUILD_SHARED_LIBS=True still offers a big advantage there: 7.5x faster
> incremental build.
>
For anyone interested in the Clang side of this discussion (Clang test
fails and incremental build times), I've started a new thread here:
http://lists.llvm.org/pipermail/cfe-dev/2019-January/060755.html
Joel
>
> Joel
>
>
>>
>> -- adrian
>>
>> Perhaps I need to do something else to prevent that. And perhaps I
>> should ask this question again on cfe-dev given that most of my rebuilds
>> affect clang.
>>
>> Thanks.
>>
>> Joel
>>
>>
>>> --
>>> Davide
>>>
>> _______________________________________________
>> lldb-dev mailing list
>> lldb-dev at lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>>
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/lldb-dev/attachments/20190108/0fc7791b/attachment-0001.html>
More information about the lldb-dev
mailing list