This is an archive of the discontinued LLVM Phabricator instance.

[JSON] Use LLVM's library for encoding JSON in GDBRemoteCommunicationServerLLGS
ClosedPublic

Authored by JDevlieghere on Oct 1 2019, 2:14 PM.

Diff Detail

Repository
rL LLVM

Event Timeline

JDevlieghere created this revision.Oct 1 2019, 2:14 PM
JDevlieghere edited reviewers, added: mgorny; removed: mgorbach.
labath accepted this revision.Oct 2 2019, 12:29 AM

Cool. Thanks for doing this.

This revision is now accepted and ready to land.Oct 2 2019, 12:29 AM
This revision was automatically updated to reflect the committed changes.
Herald added a project: Restricted Project. · View Herald TranscriptOct 2 2019, 11:01 AM

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

labath added a comment.Oct 3 2019, 1:00 AM

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... :/ )

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.

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.

labath added a comment.Oct 4 2019, 2:58 AM

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...

labath added a comment.Oct 4 2019, 3:00 AM

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).