[Lldb-commits] [PATCH] D49282: [cmake] Add option to skip building lldb-server
Alex Langford via Phabricator via lldb-commits
lldb-commits at lists.llvm.org
Mon Jul 16 13:41:28 PDT 2018
xiaobai added a comment.
In https://reviews.llvm.org/D49282#1164050, @labath wrote:
> In https://reviews.llvm.org/D49282#1163853, @xiaobai wrote:
> > In https://reviews.llvm.org/D49282#1163517, @labath wrote:
> > > I think this is fine (though the meaning of SKIP_LLDB_SERVER is subtly different than SKIP_DEBUGSERVER), but while looking at this I got an idea for a possible improvement.
> > How is it subtly different? Admittedly I haven't looked in excruciating detail, but I didn't notice any large differences.
> The main difference is that for case of SKIP_DEBUGSERVER, we take the system debugserver (which is assumed to be always present), and copy it into the build folder (I doubt we create install rules for it though). So, the result is that you always end up with a functional lldb. However, that is not the case for SKIP_LLDB_SERVER.
I see. fwiw I'm pretty sure you don't need to copy the system's debugserver, lldb should be able to detect it. I'm not sure how it will handle a system lldb-server though. What we really want is a way to avoid building lldb-server since we use our own debug server.
>>> How do you currently convince lldb to use ds2 instead of lldb-server? Do you just set the LLDB_DEBUGSERVER_PATH env var or do you do something more fancy?
>> That's one way we do that. In some situations we launch ds2 and then tell lldb to connect to it. It just depends on what you're debugging.
>>> I was thinking we could make the debugserver to use configurable at build time. That way you could build with LLDB_EXTERNAL_DEBUGSERVER=path/to/ds2.exe, which would make lldb automagically know how to launch it, and we would skip building lldb-server as a side effect.
>> I do think this would be nice, but you might have some problems later on with installation+distribution. For example, if for any reason ds2 is in a separate location on a build machine than an end-user's machine, lldb will not have a good time. This could happen if the path to ds2's build tree is used for LLDB_EXTERNAL_DEBUGSERVER instead of the path to its install location. In some cases, the path to its install location isn't necessarily known ahead of time.
> This variable was just an example. An absolute path probably wouldn't be entirely useful. We would probably need to make it relative to some other directory, or install it alongside lldb a'la SKIP_DEBUGSERVER. There are a lot of possibilities, so I'm sure we could find something that works. That is, if you're interested in such a thing in the first place.
It would be nice if we could make ds2 work in-tree or have LLDB use it nicely with CMake flags, but that's not really something interested in working on right now.
More information about the lldb-commits