[PATCH] D50365: Add a new tool named "lldb-vscode" that implements the Visual Studio Code Debug Adaptor Protocol

Fri Sep 21 13:20:04 PDT 2018

Great. Do you think that having an abstracted stream I/O tunneled through
DAP would lose anything compared to the direct file handle? I can see a few
problems using a native platform file handle:

1. It's specific to the platform (with subtle differences between platforms)
2. It assumes a local setup, where the consumer and DAP implementation are
running on the same machine, likely in the context of the same user.

If DAP had some basic read/write stream packets you can easily build a
flexible remote setup. What do you think?

On Fri, Sep 21, 2018 at 10:39 AM, Greg Clayton <clayborg at gmail.com> wrote:

>
>
> On Sep 21, 2018, at 10:31 AM, Leonard Mosescu <mosescu at google.com> wrote:
>
> The solution I would love to see is to have the initialize packet return
>> something via the DAP that says "I have a command line interpreter, please
>> send a packet with a file handle (slave path to slave side of pseudo
>> terminal maybe)". VS Code and Nuclide both emulated tty already, so we
>> could have a true command line that exposes the "(gdb)" prompt for GDB and
>> "(lldb)" for lldb and all the power that comes with it.
>>
>
> I agree, that's the main reason I asked. Having a per-DAP convention seems
> unfortunate. Also, with the current DAP messages it doesn't seem we can do
> things like auto-complete or passing control characters to the debugger
> first (ex Ctrl-C).
>
> I like your idea to manage an extra file handle. What if DAP offered
> "console stream" packets? Yet another option would be going around DAP
> completely for the pseudo terminal functionality, although it would be nice
> if everything can be built on top of DAP.
>
>
> Yeah there are two solutions to get a command line:
> 1 - have initialize packet return "I need a console named 'LLDB Commands'"
> and then have the IDE be able to switch from "Debugger Console" (which
> evaluates expressions over to "LLDB Commands" and it repurposes the
> existing debugger console to just send LLDB commands. The user would be
> able to switch between the two.
> 2 - Use a file handle to the terminals that are supported in the IDEs. The
> benefit here is the ability to due curses style output where you can
> control the cursor position and emit color control codes to colorize output.
>
>
> Not urgent but perhaps we can use LLDB to design and prototype such a DAP
> extension, then propose it to the vscode team? Is this something you'd be
> interested in?
>
>
> I would be yes. I would love the ability to due approach #2 by adding
> something to the reply to the initialize packet and if the IDE supports it,
> they will send down a file handle that could be used. Right now their TTY
> support seems to be centered around running a sub process only (like
> /bin/sh or other command line executable), not around, just give me a
> terminal and a file handle I can read and write to.
>
> Greg Clayton
>
>
>
> On Fri, Sep 21, 2018 at 9:56 AM, Greg Clayton <clayborg at gmail.com> wrote:
>
>>
>>
>> On Sep 20, 2018, at 3:05 PM, Leonard Mosescu <mosescu at google.com> wrote:
>>
>> Hi Greg, looking at request_evaluate() I noticed that it will evaluate
>> the string as a lldb command if prefixed by ` .
>>
>> This is a great feature (it allows building REPL consoles on top of DAP),
>> but I'm curious how you picked up this convention? For example I believe
>> that the gdb DAP uses -exec 'command' instead.
>>
>>
>> ` is an illegal expression character so it won't stop you from evaluating
>> any possible expression. The gdb prefix "-exec" stops you from being able
>> to negate a local variable named "exec". Not a huge deal.  So I just picked
>> a good prefix character that wouldn't stop anyone from evaluating any valid
>> expression (at least in C/C++/ObjC/Swift).
>>
>> The solution I would love to see is to have the initialize packet return
>> something via the DAP that says "I have a command line interpreter, please
>> send a packet with a file handle (slave path to slave side of pseudo
>> terminal maybe)". VS Code and Nuclide both emulated tty already, so we
>> could have a true command line that exposes the "(gdb)" prompt for GDB and
>> "(lldb)" for lldb and all the power that comes with it.
>>
>> I needed something that could run LLDB commands when things go wrong to
>> do trouble shooting (enable logging, run commands to dump vital
>> information) so I hacked it in with `
>>
>> Greg
>>
>>
>> On Thu, Aug 16, 2018 at 11:01 AM, Phabricator via Phabricator <
>> reviews at reviews.llvm.org> wrote:
>>
>>> This revision was automatically updated to reflect the committed changes.
>>> Closed by commit rL339911: Add a new tool named "lldb-vscode"
>>> that implements the Visual Studio Code Debug… (authored by gclayton,
>>> committed by ).
>>> Herald added a subscriber: llvm-commits.
>>>
>>> Changed prior to commit:
>>>   https://reviews.llvm.org/D50365?vs=161058&id=161067#toc
>>>
>>> Repository:
>>>   rL LLVM
>>>
>>> https://reviews.llvm.org/D50365
>>>
>>> Files:
>>>   lldb/trunk/lldb.xcodeproj/project.pbxproj
>>>   lldb/trunk/packages/Python/lldbsuite/test/dotest.py
>>>   lldb/trunk/packages/Python/lldbsuite/test/lldbtest.py
>>>   lldb/trunk/packages/Python/lldbsuite/test/tools/lldb-vscode/
>>> .categories
>>>   lldb/trunk/packages/Python/lldbsuite/test/tools/lldb-vscode/
>>> attach/Makefile
>>>   lldb/trunk/packages/Python/lldbsuite/test/tools/lldb-vscode/
>>> attach/TestVSCode_attach.py
>>>   lldb/trunk/packages/Python/lldbsuite/test/tools/lldb-vscode/
>>> attach/main.c
>>>   lldb/trunk/packages/Python/lldbsuite/test/tools/lldb-vscode/
>>> breakpoint/Makefile
>>>   lldb/trunk/packages/Python/lldbsuite/test/tools/lldb-vscode/
>>> breakpoint/TestVSCode_setBreakpoints.py
>>>   lldb/trunk/packages/Python/lldbsuite/test/tools/lldb-vscode/
>>> breakpoint/TestVSCode_setExceptionBreakpoints.py
>>>   lldb/trunk/packages/Python/lldbsuite/test/tools/lldb-vscode/
>>> breakpoint/TestVSCode_setFunctionBreakpoints.py
>>>   lldb/trunk/packages/Python/lldbsuite/test/tools/lldb-vscode/
>>> breakpoint/main.cpp
>>>   lldb/trunk/packages/Python/lldbsuite/test/tools/lldb-vscode/
>>> launch/Makefile
>>>   lldb/trunk/packages/Python/lldbsuite/test/tools/lldb-vscode/
>>> launch/TestVSCode_launch.py
>>>   lldb/trunk/packages/Python/lldbsuite/test/tools/lldb-vscode/
>>> launch/main.c
>>>   lldb/trunk/packages/Python/lldbsuite/test/tools/lldb-vscode/
>>> lldbvscode_testcase.py
>>>   lldb/trunk/packages/Python/lldbsuite/test/tools/lldb-vscode/
>>> stackTrace/Makefile
>>>   lldb/trunk/packages/Python/lldbsuite/test/tools/lldb-vscode/
>>> stackTrace/TestVSCode_stackTrace.py
>>>   lldb/trunk/packages/Python/lldbsuite/test/tools/lldb-vscode/
>>> stackTrace/main.c
>>>   lldb/trunk/packages/Python/lldbsuite/test/tools/lldb-vscode/
>>> step/Makefile
>>>   lldb/trunk/packages/Python/lldbsuite/test/tools/lldb-vscode/
>>> step/TestVSCode_step.py
>>>   lldb/trunk/packages/Python/lldbsuite/test/tools/lldb-vscode/
>>> step/main.cpp
>>>   lldb/trunk/packages/Python/lldbsuite/test/tools/lldb-vscode/
>>> variables/Makefile
>>>   lldb/trunk/packages/Python/lldbsuite/test/tools/lldb-vscode/
>>> variables/TestVSCode_variables.py
>>>   lldb/trunk/packages/Python/lldbsuite/test/tools/lldb-vscode/
>>> variables/main.cpp
>>>   lldb/trunk/packages/Python/lldbsuite/test/tools/lldb-vscode/vscode.py
>>>   lldb/trunk/tools/CMakeLists.txt
>>>   lldb/trunk/tools/lldb-vscode/BreakpointBase.cpp
>>>   lldb/trunk/tools/lldb-vscode/BreakpointBase.h
>>>   lldb/trunk/tools/lldb-vscode/CMakeLists.txt
>>>   lldb/trunk/tools/lldb-vscode/ExceptionBreakpoint.cpp
>>>   lldb/trunk/tools/lldb-vscode/ExceptionBreakpoint.h
>>>   lldb/trunk/tools/lldb-vscode/FunctionBreakpoint.cpp
>>>   lldb/trunk/tools/lldb-vscode/FunctionBreakpoint.h
>>>   lldb/trunk/tools/lldb-vscode/JSONUtils.cpp
>>>   lldb/trunk/tools/lldb-vscode/JSONUtils.h
>>>   lldb/trunk/tools/lldb-vscode/LLDBUtils.cpp
>>>   lldb/trunk/tools/lldb-vscode/LLDBUtils.h
>>>   lldb/trunk/tools/lldb-vscode/README.md
>>>   lldb/trunk/tools/lldb-vscode/SourceBreakpoint.cpp
>>>   lldb/trunk/tools/lldb-vscode/SourceBreakpoint.h
>>>   lldb/trunk/tools/lldb-vscode/SourceReference.h
>>>   lldb/trunk/tools/lldb-vscode/VSCode.cpp
>>>   lldb/trunk/tools/lldb-vscode/VSCode.h
>>>   lldb/trunk/tools/lldb-vscode/VSCodeForward.h
>>>   lldb/trunk/tools/lldb-vscode/lldb-vscode-Info.plist
>>>   lldb/trunk/tools/lldb-vscode/lldb-vscode.cpp
>>>   lldb/trunk/tools/lldb-vscode/package.json
>>>
>>>
>>
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20180921/c4702c84/attachment.html>