Page MenuHomePhabricator

[cmake] Add option to skip building lldb-server
ClosedPublic

Authored by xiaobai on Jul 12 2018, 11:55 PM.

Details

Summary

There is currently a way to skip the debugserver build. See how the CMake
variables SKIP_DEBUGSERVER and LLDB_CODESIGN_IDENTITY are used if you're
interested in that.

I'd like the option to skip buildng lldb-server as well. I work on a debug
server called ds2 and I often don't need to build lldb-server when I build lldb.

Diff Detail

Repository
rL LLVM

Event Timeline

xiaobai created this revision.Jul 12 2018, 11:55 PM
sas accepted this revision.Jul 13 2018, 12:29 PM
This revision is now accepted and ready to land.Jul 13 2018, 12:29 PM
xiaobai updated this revision to Diff 155459.Jul 13 2018, 12:40 PM

Update unittest logic.

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 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?

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 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.

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.

The option would be fine for lldb-server and debugserver though, since they (in general) will have well-known locations if already present on your system (e.g. an xcode related directory).

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.

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.

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.

This revision was automatically updated to reflect the committed changes.