Debugging breaks in Xcode 12.1+ with external module maps

[michaeleisel]

Xcode has been complaining about missing module maps at <workspace root>/external/.../module.modulemap for some time, but it seems in Xcode 12.1+ that it's actually causing an LLDB RPC crash for us when trying to run po <anything>. Looking at the dSYM, I see relative paths of the form external/.../module.modulemap, as well as module maps of the form bazel-client/.../module.modulemap for non-external rules. The latter seems to work, but not the former. I can fix it by adding ln -s <workspace root>/bazel-client/external <workspace root>/external, but I'd really like to avoid adding symlinks like this to the top level. How does this work in the first place? How does LLDB's "working directory" seem to be set to the workspace root at all? And how might I fix this?

[cpsauer]

Michael, is the name of your workspace "c"? That is, is this the same workaround I'd found in #164?

[michaeleisel]

Yes, the same workaround, and one which I want to avoid

[michaeleisel]

I've updated it to use bazel-client to be clearer

[thii]

Are you hardcoding the path to your module map file like -fmodule-map-file=external/path/to/module.modulemap? If the path is expanded by Bazel then it will be mapped by Tulsi to be something like -fmodule-map-file=$(TULSI_BWRS)/external/path/to/module.modulemap, which would be an existing path.

[michaeleisel]

The relevant module map line, at least for swiftc, appears to be -Xcc -fmodule-map-file=external/path/to/module.modulemap. This is in the arguments list given to swiftc by Bazel, and this path isn't hardcoded, it's just automatically created from depending on that rule. Where would Tulsi do such a mapping? In the dsymutil invocation? (the tulsi section of .lldbinit has no mappings for me)

[thii]

(I shouldn't have used the word "map".)

In the generated Xcode project's "Other Swift Flags" setting, the module map flags become -Xcc -fmodule-map-file=$(TULSI_BWRS)/external/path/to/module.modulemap (Tulsi prepends $(TULSI_BWRS)/ to the file path). Since $(TULSI_BWRS) is a symlink to the exec root, that path resolves to the correct file.

[michaeleisel]

But that would only affect files compiled in that target, right? I.e., only affecting indexing and not debugging. That means it wouldn't apply to these .o files compiled in the bazel build.

[DavidGoldman]

Interesting, yeah for indexing Tulsi has the symlink there, but for debugging lldb will have trouble finding it since lldb isn't given the proper working directory (it'll be / by default and we use target.source-map/dSYM path remappings to remap some other information). If you try something like bazel-ios/rules_ios#127 to make the bazel execution root the working directory does it work?

[thii]

Would adding mapping for external to target.source-map work? Something like:

settings set target.source-map "./external/" "/path/to/main/repo/bazel-repo/external/"
settings append target.source-map "./" "/path/to/main/repo/"

[DavidGoldman]

Yeah, that's worth a shot (wonder if you need to remap external/ or ./external/) - could work as long as it doesn't conflict with the workspace root remapping.

[keith]

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