[lldb-dev] debugserver and llvm

[Greg Clayton via lldb-dev]

> On Aug 27, 2016, at 3:14 PM, Zachary Turner via lldb-dev <lldb-dev at lists.llvm.org> wrote:
> 
> What is the status of using LLVM from debugserver?  AFAICT, it doesn't use llvm, but it DOES use some lldb private libraries, in which case it is already implicitly linking against LLVM anyway.
> 
> So why can't LLVM headers be included and used from debugserver?  Just now I was changing the signature of an LLDB function to include an llvm header, and I got everything working and ready to go but searched through code that doesn't compile on Windows, and I noticed that debugserver includes some headers from lldb, and since those lldb headers are including llvm headers, I'm assuming this is not going to work.  But I think I'm missing something, because AFAICT this will already cause a link dependency from debugserver to llvm, and has been for some time.  So I'm not entirely sure what the status is of this.
> 
> In any case, I know the easy way out is to just say don't include an llvm header from that lldb header, but I don't think that's a great idea as I think the patch I'm working on is a big win for performance, code readability, and simplicity.
> 
> It looks like there is already precedent for debugserver to copy some code from lldb and keep a local copy in debugserver, for example JSON.h and JSON.cpp seem to be copies of the code from lldb/Utility.  Can this be done for StringExtractor.h as well so that I can reference llvm from within StringExtractor.h in lldb?

debugserver currently doesn't link against any of the llvm .a files so I don't think it can be using any llvm stuff unless it uses header file only inlined functions. We aren't going to spend any time on this and we have builds of debugserver that link against even less (debugserver-mini) that the normal debugserver. So I advise you don't change debugserver's link requirements as we build it in many different places and we don't always build llvm when we build, so debugserver can't have requirements to link against llvm or clang .a files.

For one I would prefer to leave StringExtractor alone. It uses the std::string to store the packet content and we want that the remain as is. I am fine with coming up with a replacement StringRefExtractor.h/.cpp that uses an llvm::StringRef that we cut over to using internally in LLDB, but again, for anyone needing the data to stay stored somewhere, they should use StringExtractor.cpp.