[lldb][CMake] Workaround debugserver code-signing issue in generated Xcode project

[sgraenitz]

Summary

Explicitly code-sign the LLDB.framework copy of debugserver in the build-tree. This is necessary, because the Xcode-specific logic in llvm_codesign [1] has the side-effect that Xcode code-signs after post-build steps (here: after copying debugserver over into the framework). The special case for Xcode was necessary to avoid double-signing errors in the past (see D55116 and D55816).

[1] https://github.com/llvm/llvm-project/blob/36fb93982f0e/llvm/cmake/modules/AddLLVM.cmake#L1676

[sgraenitz]

Checked with:

> xcodebuild -configuration Release -target debugserver
> codesign -dv Release/bin/LLDB.framework/Versions/A/Resources/debugserver
> codesign -dv Release/bin/debugserver

lldb/tools/debugserver/source/CMakeLists.txt

233 ↗

(On Diff #212762)

This forces code-signing and may cause double-signing warnings.

[JDevlieghere]

Is there a way to use the debugserver in the framework instead? This seems like the inverse of the problem we had earlier with the RPATHs, where we would fix them up in the build tree after copying them.

[sgraenitz]

In D65566#1611007, @JDevlieghere wrote:

Is there a way to use the debugserver in the framework instead?

This patch is about the debugserver in the framework. It must be signed, because the lldb driver uses it implicitly and, apparently, that is the correct behavior.
debugserver is built as bin/debugserver and copied to bin/LLDB.framework/Resources/debugserver (the latter is currently not signed in Xcode builds).

This seems like the inverse of the problem we had earlier with the RPATHs, where we would fix them up in the build tree after copying them.

It's purely about the functionality of the build-tree lldb.

BTW The problem you may refer to (--> https://reviews.llvm.org/D61952#change-2C1slKxbErMH ?) is unrelated, but it's still existing when installing with the framework. Currently it doesn't show up upstream, because in practice configuration-order defines install-order. So, we are good as long as tools that go into the framework are configured after the framework.

[JDevlieghere]

In D65566#1612051, @sgraenitz wrote:

In D65566#1611007, @JDevlieghere wrote:

Is there a way to use the debugserver in the framework instead?

This patch is about the debugserver in the framework. It must be signed, because the lldb driver uses it implicitly and, apparently, that is the correct behavior.
debugserver is built as bin/debugserver and copied to bin/LLDB.framework/Resources/debugserver (the latter is currently not signed in Xcode builds).

Ok, thanks, I misunderstood and thought it was the other way around.

This seems like the inverse of the problem we had earlier with the RPATHs, where we would fix them up in the build tree after copying them.

It's purely about the functionality of the build-tree lldb.

BTW The problem you may refer to (--> https://reviews.llvm.org/D61952#change-2C1slKxbErMH ?) is unrelated, but it's still existing when installing with the framework. Currently it doesn't show up upstream, because in practice configuration-order defines install-order. So, we are good as long as tools that go into the framework are configured after the framework.

Yep, that's the thing I had in mind.

Anyway, what I was trying to express is that this change feels ad-hoc and I'm wondering if we can tackle it more structurally.

[sgraenitz]

Solutions are clearly favorable over workarounds like this, but I couldn't find one. Xcode has a mechanism called sign on copy which seems to be the native way to avoid this problem, but I couldn't get it to work with LLDB, because I want to copy the build output of a target and this caused a cyclic dependency. I didn't find more information about it and there seems to be no way to generate this behavior with CMake. The only way around seems to be a custom script, but that is no better than the workaround here.

Given the situation, that the problem is a symptom (1) of a workaround (2) that avoids a misbehavior of xcodebuild (3), I think the given fix is acceptable.

(1) copied debugserver not signed
(2) Xcode-specific signing process that avoid double-signing
(3) xcodebuild runs post-build steps even though the target was not built

[JDevlieghere]

Okay, sounds like the best possible solution.

lldb/trunk/tools/debugserver/source/CMakeLists.txt

 endif()
 set(LLVM_OPTIONAL_SOURCES ${lldbDebugserverCommonSources})
 add_lldb_tool(debugserver ADD_TO_FRAMEWORK
   debugserver.cpp
   LINK_LIBS lldbDebugserverCommon
   ENTITLEMENTS ${entitlements}
 )
 
+# Workaround for Xcode-specific code-signing behavior:
+# The XCODE_ATTRIBUTE_CODE_SIGN_IDENTITY option causes debugserver to be copied
+# into the framework first and code-signed afterwards. Sign the copy manually.
+if (debugserver_codesign_identity AND LLDB_BUILD_FRAMEWORK AND
+    CMAKE_GENERATOR STREQUAL "Xcode")
+  if(NOT CMAKE_CODESIGN_ALLOCATE)
+    execute_process(
+      COMMAND xcrun -f codesign_allocate
+      OUTPUT_STRIP_TRAILING_WHITESPACE
+      OUTPUT_VARIABLE CMAKE_CODESIGN_ALLOCATE
+    )
+  endif()
+  if(entitlements)
+    set(pass_entitlements --entitlements ${entitlements})
+  endif()
+
+  get_target_property(framework_build_dir liblldb LIBRARY_OUTPUT_DIRECTORY)
+  set(copy_location ${framework_build_dir}/LLDB.framework/Versions/${LLDB_FRAMEWORK_VERSION}/Resources/debugserver)
+
+  add_custom_command(TARGET debugserver POST_BUILD
+    COMMAND ${CMAKE_COMMAND} -E
+            env CODESIGN_ALLOCATE=${CMAKE_CODESIGN_ALLOCATE}
+            xcrun codesign -f -s ${debugserver_codesign_identity}
+            ${pass_entitlements} ${copy_location}
+    COMMENT "Code-sign debugserver copy in the build-tree framework: ${copy_location}"
+  )
+endif()
+
 set_target_properties(debugserver PROPERTIES FOLDER "lldb libraries/debugserver")
 
 if(IOS)
   set_property(TARGET lldbDebugserverCommon APPEND PROPERTY COMPILE_DEFINITIONS
     WITH_LOCKDOWN
     WITH_FBS
     WITH_BKS
     )