This patch replaces the LLDB's JSON implementation with the one from
LLVM in GDBRemoteCommunicationServerLLGS.
Details
- Reviewers
labath vsk mgorny - Commits
- rG9beb45671bac: [JSON] Use LLVM's library for encoding JSON in GDBRemoteCommunicationServerLLGS
rLLDB373497: [JSON] Use LLVM's library for encoding JSON in GDBRemoteCommunicationServerLLGS
rL373497: [JSON] Use LLVM's library for encoding JSON in GDBRemoteCommunicationServerLLGS
Diff Detail
- Repository
- rL LLVM
Event Timeline
FYI, we've root caused some internal lldb asan failures to this patch. I don't have a repro yet (my lldb tests seem to be failing locally for unrelated reasons), but e.g. Register/x86-64-read.test is failing to read all the non-general purpose registers:
(lldb) register read --all General Purpose Registers: rax = 0x00007fffffffd660 ... etc. ... Floating Point Registers: 42 registers were unavailable. Advanced Vector Extensions: 16 registers were unavailable. Memory Protection Extensions: 6 registers were unavailable. (lldb) process continue error: Failed to resume process: Resume timed out..
These tests are passing in all other modes, including other sanitizer modes
FYI, we've root caused some internal lldb asan failures to this patch. I don't have a repro yet (my lldb tests seem to be failing locally for unrelated reasons)
This should be fixed with r373572.
BTW, are you sure those reasons were unrelated? If you have had nearly every test failing then it was very likely due to this. (The reason only a couple of tests failed for you in asan mode is because our CI does not run a large chunk of the lldb tests... :/ )
Thanks!
BTW, are you sure those reasons were unrelated? If you have had nearly every test failing then it was very likely due to this. (The reason only a couple of tests failed for you in asan mode is because our CI does not run a large chunk of the lldb tests... :/ )
Yes, tests are still failing locally for me, e.g. Driver/TestConvenienceVariables.test in ninja check-lldb-driver fails:
Command Output (stderr): -- Traceback (most recent call last): File "<string>", line 1, in <module> ImportError: No module named lldb.embedded_interpreter Traceback (most recent call last): File "<string>", line 1, in <module> NameError: name 'run_one_line' is not defined Traceback (most recent call last): File "<string>", line 1, in <module> NameError: name 'run_one_line' is not defined Traceback (most recent call last): File "<string>", line 1, in <module> NameError: name 'run_one_line' is not defined Traceback (most recent call last): File "<string>", line 1, in <module> NameError: name 'run_one_line' is not defined Traceback (most recent call last): File "<string>", line 1, in <module> NameError: name 'run_one_line' is not defined Traceback (most recent call last): File "<string>", line 1, in <module> NameError: name 'run_one_line' is not defined error: python failed attempting to evaluate 'print(lldb.debugger)'
I think it's a python-related misconfiguration somewhere about not finding the lldb module, but I'm not sure when it started -- these tests used to pass, but I nuked my cmake tree and apparently didn't reconfigure it correctly.
Yeah, that's definitely python-related, but it's hard to say how exactly without knowing more details. Also note that there have been some changes in how the python stuff is used/built in the last couple of weeks so it's possible this was not caused by a change on your side...
TBE, this happens when lldb is not able to find the python package files (which should normally be in $BUILD/libXY/pythonA.B/site-packages).