Page MenuHomePhabricator

Support Unit Testing debugserver

Authored by beanz on Mar 24 2017, 3:00 PM.



This patch refactors the CMake build system's support for building debugserver to allow us to build the majority of debugserver's sources into the debugserverCommon library which can then be reused by unit tests.

The first unit test I've written tests debug server's ability to accept incoming connections from LLDB. The test forks the process, and one side creates a listening socket using debugserver's socket API, the other side creates a transmitting socket using LLDB's TCPSocket class.

I have no clue where to even start getting this connected into the LLDB Xcode project, so for now these tests are CMake-only.

Event Timeline

beanz created this revision.Mar 24 2017, 3:00 PM
jingham added a subscriber: jingham.EditedMar 24 2017, 4:13 PM

Todd added a gtest target to the lldb.xcodeproj. Presumably you could use that as a template and do the same thing in the tools/debugserver/debugserver.xcodeproj. Then make an aggregate target in the lldb workspace that runs these two targets.

beanz added a comment.Mar 24 2017, 4:23 PM

Xcode is pretty magic to me. I don't know how to do much of anything in it other than build. I think the right solution would be to take most of the source files out of the debugserver target and generate a static archive from them, then have debugserver and the debugserverTest target link the static archive.

I don't know how to do that and not screw up the Xcode target settings on the archive target.

beanz updated this revision to Diff 93165.Mar 27 2017, 12:17 PM

Fleshed out the unit test logic to be more meaningful.

jingham added a comment.EditedMar 27 2017, 12:32 PM

It's a little weird to have the unit tests for debugserver in the top-level lldb directory's unittests. debugserver really is a stand-alone tool that shares no code with lldb proper. How hard would it be to put the tests under debugserver?

@jingham I put the unit tests at the top because they depend on LLDB's Host library (at least the current tests do). I'm attempting to write tests which cover the socket communication between LLDB and debugserver by sending data between the two using each side of the API.

debugserver only runs on darwin and we have no intentions of using it elsewhere. lldb-server is the way to do debugserver for new platforms. I don't think you need the generality provided by host to test debugserver, OTOH, if using those classes saves you lots of time over writing macOS specific code, then I'm mostly concerned that it is clear that debugserver isn't the way to do debug servers for lldb, lldb-server is...

beanz updated this revision to Diff 93190.Mar 27 2017, 3:55 PM

Added a note to the unit test CMake file about why the tests are where they are. Generally we isolate debugserver from the rest of LLDB, and this comment explains the breach of isolation.

labath edited edge metadata.Mar 28 2017, 9:21 AM

I am afraid I will be away for two weeks as well.. :(

The FileLogCallback thingy seems a bit unfortunate, but I don't see anything too controversial based on a quick scan..

beanz updated this revision to Diff 94374.Apr 6 2017, 8:22 AM

Some cleanup to the test case:

  • Auto-select a port, which will make this more reliable
  • Open listening sockets before the fork() so that the sockets are ready for connection (this avoids a race)
  • Put test logic into reusable functions so that test logic can be reused for IPv6 tests when I add them

Adding Jim as a reviewer.

Jim, with the added comment about debugserver being Darwin-only, are you happy with this patch?

jingham edited edge metadata.Apr 6 2017, 10:39 AM

On the small points side: for lldb code we use lower-case, _ separated names for local variables, the point being that it allow you to tell at a glance what's a local and what's an ivar. Looks like you use a mixture of the two styles? exit_status, result, etc. alongside WriteSize, etc... It doesn't matter as much for a test case, but still it's good to be consistent.

More substantial, what happens to a gtest case if the test case program aborts? Remembering that the way the world works, this failure is bound to happen only intermittently on some server you can't access, so it's good to collect as much info as you can on failure. If the tests report a good stack trace on abort, that's probably fine, but otherwise it would be good to figure out a way to back out and leave some trace.

beanz added a comment.Apr 6 2017, 10:41 AM

I will fix up the naming conventions. Switching back and forth between LLVM and LLDB conventions has done a number on my brain.

The test cases only abort on the child process side of the fork calls. This results in printing a stack trace, but it also will get captured as a failure because the parent process side checks the exit status of the child.

beanz updated this revision to Diff 94526.Apr 7 2017, 8:52 AM

Fixing variable naming conventions

labath accepted this revision.Apr 11 2017, 5:44 AM

This is fine, as far as i am concerned.


The comment does not make sense anymore.

This revision is now accepted and ready to land.Apr 11 2017, 5:44 AM
This revision was automatically updated to reflect the committed changes.