[lldb-dev] How to test lldb-vscode?

Thu Feb 15 02:52:02 PST 2018

Mocking the VS side (in python or C++) sounds like the way to go.

I don't know much smartness is in this code (as in, something other
than "take this json, translate it to an appropriate SB call and
serialize the results back"), but if there is some non-trivial logic
in there (perhaps the code for handling the wire protocol itself),
then this would be a good candidate for a unit test.

On 15 February 2018 at 01:10, Jim Ingham via lldb-dev
<lldb-dev at lists.llvm.org> wrote:
> The SB API's were designed to be binary stable API's when used either from C++ or Python (the latter are just a SWIG-ified version of the former.)  So just like the Python wrapper, with the exception that you might call an API that some older version of liblldb doesn't provide, Greg's adaptor wouldn't be sensitive to lldb library version.
>
> Jim
>
>
>> On Feb 14, 2018, at 4:43 PM, Vadim Chugunov via lldb-dev <lldb-dev at lists.llvm.org> wrote:
>>
>> My tests are here.   I probably wouldn't move all that to Python for my extension, but feel free to draw ideas on things to test from it.
>>
>> What's going to be your deployment story?   The nice thing about Python-based adapter is that it will run on a wide range on LLDB versions.  For a native adapter you'll need to somehow make sure that you have the right liblldb installed, won't you?
>>
>>
>> On Wed, Feb 14, 2018 at 3:54 PM, Greg Clayton <clayborg at gmail.com> wrote:
>>
>>
>>> On Feb 14, 2018, at 3:45 PM, Vadim Chugunov <vadimcn at gmail.com> wrote:
>>>
>>> FYI - I've been maintaining a similar VSCode extension, which does it all through LLDB's Python interface.
>>
>> Indeed, I saw you plug-in and since it worked so well I wanted to make a native version of this plug-in to avoid taking over the python interpreter and get native performance. Very nice work on that plug-in as it inspired this one! I adopted many similar settings that you allow in the launch.json file and added some new ones.
>>
>>>
>>> As for testing, the protocol is JSON with HTTP-like headers for framing, so you could have a Python script emulating the VSCode side.
>>
>> That is what I was planning to do. Might be nice to work together on this and get the testing working as it could test both of our plug-ins. Would be great to have a debug session with a simple program that sets a breakpoint by name, by file and line and exception and run, hit the breakpoints, view variables, etc.
>>
>> Greg
>>
>>>
>>>
>>> On Wed, Feb 14, 2018 at 2:28 PM, Greg Clayton via lldb-dev <lldb-dev at lists.llvm.org> wrote:
>>> I have a patch I will be submitting soon that adds a tool called "lldb-vscode" that is much like "lldb-mi" where it sits on top of LLDB.framework on Darwin and liblldb.so on all other platforms, and it speaks the Visual Studio Code Debug adaptor language and can be used to create a VSCode extension that does native LLDB debugging. The plug-in works really well to debug native apps and is very responsive and quick.
>>>
>>> One issue I am thinking about is how to test this. Some VS Code tests out there use Javascript + npm to run a mock VSCode IDE and send/receive packets. I am not sure we can require people to have this on all build bots. So I am writing to get everyone's opinion on this so I can test this and get a patch submitted.
>>>
>>> Any ideas would be appreciated.
>>>
>>> Greg Clayton
>>>
>>> _______________________________________________
>>> lldb-dev mailing list
>>> lldb-dev at lists.llvm.org
>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>>>
>>
>>
>> _______________________________________________
>> lldb-dev mailing list
>> lldb-dev at lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev
>
> _______________________________________________
> lldb-dev mailing list
> lldb-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev