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

Greg Clayton via lldb-dev lldb-dev at lists.llvm.org
Fri Jul 12 15:33:25 PDT 2019


Fine to refactor any way that makes it easier for people to re-use or add new VS Code DAP plug-ins! I agree with all comments so far.

Greg

> On Mar 13, 2019, at 12:50 AM, Pavel Labath via lldb-dev <lldb-dev at lists.llvm.org> wrote:
> 
> 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/.
> 
> regards,
> pl
> _______________________________________________
> lldb-dev mailing list
> lldb-dev at lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-dev



More information about the lldb-dev mailing list