Open 07151129 opened 9 years ago
Ok, here is a patch. DVTFilePath
-related stuff is for fixing the crash when configuring VCS:
DVTAssertions: ASSERTION FAILURE in /Library/Caches/com.apple.xbs/Sources/DVTFrameworks/DVTFrameworks-8114.24/DVTFoundation/FilePaths/DVTFilePath.m:896 Details: url should be an instance inheriting from NSURL, but it is nil Object: <DVTFilePath> Method: +filePathForFileURL: Thread: <NSThread: 0x7fb5e2518430>{name = (null), num = 1} Hints: None
Unfortunately, it does not help (method does not get hooked properly?…), and I am too tired for that.
I had to add libgnu fstatat
implementation.
For some reason, installing packages from Resources/Packages
failed (performed by Xcode after accepting license); I had to do it manually.
UPD: VCS problem seems to be relevant to lack of necessary symbols (rebound by XPF) in com.apple.dt.Xcode.sourcecontrol.* XPC services.
It seems like that some symbols are not rebound for created subprocesses. For instance, simulator refuses to start because of system version check. This would also explain Xcode not being able to install the packages.
There is another problem with +[DVTFilePath filePathForFileURL:]
: assertion [(url) isKindOfClass:[NSURL class]]
failed; the URL turned out to be an instance of NSString
. I solved it by redirecting the calls to +[DVTFilePath filePathForPathString:]
in ideplugin using [[PLPatchMaster master] patchFutureClassWithName:]
, but there might be a better solution.
UPD: Indeed, dyld ignores DYLD_* envvars for subrpocesses (restriction by private entitlements?). Also, the image name check should be extended against a list of images instead...
Just some notes:
Ultimately, I think Xcode 7 support might require graduating from DYLD_* insertion and actually performing runtime code injection from a privileged position.
Thank you for your reply! Indeed, it seems to be a good option to switch to something more powerful for injection (e.g, comex' Substitute?). We ourselves are using a kernel-space patcher for this. The patch is actually for xcode7 support branch, it's just that github does not separate issues based on branch. It's not like it is of much use now anyway, since it needs some more fixes. I will submit a PR if/when it's done. P.S. I am actually surprised by how simple the principle of XPF is; perhaps, one day we could build a generalised backporting framework based on it?…
Indeed, it seems to be a good option to switch to something more powerful for injection (e.g, comex' Substitute?). We ourselves are using a kernel-space patcher for this.
Huh, neat. I've been playing around with kexts to hook exec/spawn* -- I'll have to look at Substitute in more detail.
P.S. I am actually surprised by how simple the principle of XPF is; perhaps, one day we could build a generalised backporting framework based on it?…
I've had similar thoughts. We're not very far away from having a full-fledged dyld replacement, and if we can do arbitrary binary injection/patching:
I have only tested it for Xc7, but it seems like xcodebuild checks
DVTMinimumSystemVersion
atxcodebuild:10000142c (com.apple.xbs/Sources/IDETools/IDETools-8027/xcodebuild/xcodebuild_main.m:checkMinimumOSVersion)
. The version itself is stored in info.plist in __TEXT of xcodebuild binary. If the check fails, then Xcode fails to install developer tools, and so it won't let user in past the license view. As a workaround, I suggest implementing something like xpf_patch_info_dictionary, but this time for that nasty key :)(This is, of course, only a peak of the iceberg. I am still working on making it actually run xc7b2 and will report when done...)