Cannot debug Objective-C

[FuegoFro]

Hi! Wasn't sure if I should post this as a comment on https://github.com/bazelbuild/tulsi/issues/16 or open a new issue. If you think this belongs on https://github.com/bazelbuild/tulsi/issues/16 I'm happy to close this and re-post it there 🙂

I'm unable to get Objective-C debugging working with Xcode at all, though I'm unsure if I'm missing steps (since it is claimed to be working as of https://github.com/bazelbuild/tulsi/commit/cb9a6cd49d73da11a406fb8724d19d4c268df02f). I've updated the example project in the description of https://github.com/bazelbuild/tulsi/issues/16 to use newer versions of the external dependencies, and am unable to get Xcode to register a breakpoint in the Simple.m file: https://github.com/FuegoFro/debugging-tulsi-broken

This was generated with Tulsi 0.20190501.88 (built from https://github.com/bazelbuild/tulsi/commit/1360ceee0941d5f62c89eece5e7006ad691d7e44), with both Tulsi and the project built with Bazel version

Build label: 0.24.1
Build target: bazel-out/darwin-opt/bin/src/main/java/com/google/devtools/build/lib/bazel/BazelServer_deploy.jar
Build time: Tue Apr 2 16:32:47 2019 (1554222767)
Build timestamp: 1554222767
Build timestamp as int: 1554222767

I'm using Xcode 10.2.1 (10E1001).

I've tried both with blank 'build' options and with it set to --strategy=ObjcCompile=standalone (as suggested in https://github.com/bazelbuild/tulsi/issues/52 and https://github.com/bazelbuild/tulsi/commit/cb9a6cd49d73da11a406fb8724d19d4c268df02f), including various combinations of restarting Xcode, running bazel clean --expunge, and deleting and re-adding the breakpoint.

In all of these tests, the app just ran right past the log line without breaking/stopping.

Some other information that may or may not be relevant (I'm not super familiar with how a lot of this stuff works):

• If I pause the app using Xcode's "Pause program execution" and run the b command I get

(lldb) b
Current breakpoints:
1: file = 'Sources/Public/Simple.m', line = 7, exact_match = 0, locations = 0 (pending)

• If I look at the final binary with nm the SO paths have a ./ in front of them and the OSO paths point to locations that don't exist (even when --strategy=ObjcCompile=standalone):

$ nm -pa bazel-out/ios-x86_64-min9.0-applebin_ios-ios_x86_64-dbg/bin/FullBazelSample.__internal__.apple_binary_bin | head -n 3
0000000000000000 - 00 0000    SO ./
0000000000000000 - 00 0000    SO AppDelegate.m
0000000000000000 - 03 0001   OSO /private/var/tmp/_bazel_danny.weinberg/7c3fa8d5c40482cf9bff6a01c879a695/sandbox/darwin-sandbox/6/execroot/__main__/bazel-out/ios-x86_64-min9.0-applebin_ios-ios_x86_64-dbg/bin/libLib.a(AppDelegate_71bcb7619b7e923a2cb6a076b7f1a227.o)

Is this a bug in Tulsi? Am I missing some step needed to allow debugging to work?

Thank you ahead of time!

[DavidGoldman]

Haven't had time to try reproducing this locally, but I'd recommend trying:

• Add --apple_generate_dsym to your build flags to see if it helps

Are you sure that the files referenced by the OSO don't exist? Even after a bazel clean --expunge and then a build with --strategy=ObjcCompile=standalone? Without dSYMs, debugging won't work properly if those files don't exist.

[FuegoFro]

Thank you for the response! Adding --apple_generate_dsym does indeed allow me to debug the sample project I posted! I'm going to try it on my larger project and see if that works as well.

Interestingly, yeah, even after bazel clean --expunge and with --strategy=ObjcCompile=standalone the OSO doesn't exist. Setting --strategy=ObjcLink=standalone and --strategy=CppLink=standalone, on the other hand, did make it such that the OSO paths point to valid files.

[DavidGoldman]

Ah, that makes sense - sandboxing for the linker action means those paths may not exist after the linking action runs, I'll ask around

[FuegoFro]

Just wanted to follow up that on my larger project passing --apple_generate_dsym worked as well! Thank you for the hint/advice!

I'm not sure if it's expected that this flag needs to be set. If so, then we can go ahead and close this out. Otherwise it may make sense to keep this issue open to track the fact that debugging doesn't work out of the box. I'll leave that up to you though 🙂

[kkpattern]

I think we don't need --apple_generate_dsym or link strategy local for debugging. After some tests, we found that if the following conditions are met, the debug will work:

1. -g(--apple_generate_dsym will automatically add this flag)
2. --strip=never
3. --features=oso_prefix_is_pwd

The --features=oso_prefix_is_pwd will convert the absolute path of OSO to a relative path. This both avoids setting link strategy to local and solving the remote cache problem(without oso_prefix_is_pwd, even if we set link strategy to local, other developers won't be able to debug if they download the result from the remote cache).

Consider we already add --features=debug_prefix_map_pwd_is_dot to DebugPathNormalization in tulsi, maybe we should add --features=oso_prefix_is_pwd to DebugPathNormalization too? I think in this way, most users will have debug objc working out of the box. If this is OK I'd like to make a PR.

Adding --apple_generate_dsym will also make debugging work. However, the link time will be significantly longer for large projects.

[kkpattern]

Oh, --features=oso_prefix_is_pwd only be supported since Xcode 11. I don't know how many developers still use Xcode that are older than 11.

[keith]

Thanks for submitting this issue but this tool is being deprecated. Please checkout rules_xcodeproj for a more complete and maintained Xcode integration.