[lldb-dev] Needs help contributing to lldb-vscode.

Pavel Labath via lldb-dev lldb-dev at lists.llvm.org
Wed Mar 13 00:50:25 PDT 2019

On 12/03/2019 20:34, Leonard Mosescu via lldb-dev wrote:
> Greg, what do you think?
> On Tue, Mar 12, 2019 at 11:50 AM Qianli Ma <chienlima at google.com 
> <mailto:chienlima at google.com>> wrote:
>     Hi lldb community,
>     I am currently working on a project related to lldb. I'd like to
>     write a DAP RPC server similars to lldb-vscode.cc
>     <https://github.com/llvm-mirror/lldb/blob/master/tools/lldb-vscode/lldb-vscode.cpp> but
>     exports I/O to internal RPC clients. Doing so requires me to reuse
>     some functions defined in lldb-vscode.cc
>     <https://github.com/llvm-mirror/lldb/blob/master/tools/lldb-vscode/lldb-vscode.cpp>.
>     However as those functions are defined using forward declaration I
>     am not able to do that.
>     I'd like refactor the code a bit. More specifically, I'd like to
>     extract all helper functions in lldb-vscode.cc
>     <https://github.com/llvm-mirror/lldb/blob/master/tools/lldb-vscode/lldb-vscode.cpp> into
>     a separate file and create a header for it.  BTW, IMO it's good to
>     make this lldb-vscode more general so that it can be used by other
>     debugger frontends besides vscode.
>     Please let me know WDYT and how I can proceed to submit changes for
>     review.
>     Thanks and Regards
>     Qianli

The way I understand this idea, you want to make (parts of) lldb-vscode 
a library. The way this is usually done in llvm is that you put all of 
the library stuff in a separate folder, with its own headers, cmake 
target and everything. Then, you can make lldb-vscode executable (or 
whatever its called) link against that library. Your downstream tool can 
do the same.

I think doing that is a good idea. The only part we need to figure out 
is where to put the new library code. Normally, all our library-ized 
code lives under source/, but this library would be special in that it 
sits on top of the SB api rather than beneath it. So, even though it 
sounds a weird to have a library living under tools/, it might be better 
to have the new library be there instead of under source/.


More information about the lldb-dev mailing list