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

Greg Clayton via lldb-commits lldb-commits at lists.llvm.org
Mon Sep 24 14:25:59 PDT 2018 

Sounds good!

> On Sep 24, 2018, at 10:45 AM, Leonard Mosescu <mosescu at google.com> wrote:
> 
> Thanks Greg, this is what I had in mind. 
> 
> I have some ideas which involve this kind of debugger console. We'll likely start with a basic version built on top of evaluate `cmd and once we get around to building a full console I'll ping you.
> 
> On Sat, Sep 22, 2018 at 8:50 AM, Greg Clayton <clayborg at gmail.com <mailto:clayborg at gmail.com>> wrote:
> 
> 
>> On Sep 21, 2018, at 1:20 PM, Leonard Mosescu <mosescu at google.com <mailto:mosescu at google.com>> wrote:
>> 
>> 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?
> 
> Yeah, I forgot about remote. Maybe best to set it all up through DAP and just tell the IDE that you have a command interpreter and maybe what its prompt should be. 
> 
> The init packet would be sent:
> 
> {"command":"initialize","type":"request","seq":1, "arguments":{...}}
> 
> Then in the response we would say we have an interpreter:
> 
> {"command":"initialize","type":"response", "request_seq":1,"seq":0,"success":true,"body":{
>     "supportsCommandInterpreter":true, 
>     "interpreterPrompt":"(lldb)"
>   }
> }
> 
> 
> Then the IDE would need to support output going into (STDIN) that would go to the command interpreter somehow, and accept output coming from the command interpreter via the "output" event by adding support for a new output type "interpreter":
> 
> {"event":"output","seq":0,"type":"event", "body":{"category":"interpreter","output":"output text here"}}
> 
> Then the IDE would only need either have another window for the interpreter, or allow the standard debugger console to be switched over into interpreter mode and show both outputs there.
> 
> 
>> 
>> On Fri, Sep 21, 2018 at 10:39 AM, Greg Clayton <clayborg at gmail.com <mailto:clayborg at gmail.com>> wrote:
>> 
>> 
>>> On Sep 21, 2018, at 10:31 AM, Leonard Mosescu <mosescu at google.com <mailto: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 <mailto:clayborg at gmail.com>> wrote:
>>> 
>>> 
>>>> On Sep 20, 2018, at 3:05 PM, Leonard Mosescu <mosescu at google.com <mailto: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 <mailto: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 <https://reviews.llvm.org/D50365?vs=161058&id=161067#toc>
>>>> 
>>>> Repository:
>>>>   rL LLVM
>>>> 
>>>> https://reviews.llvm.org/D50365 <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/lldb-commits/attachments/20180924/fd9953b5/attachment-0001.html>

More information about the lldb-commits mailing list