Xcode could not resolve type from dSYM if build folder is different

One things that's suspicious in your log is that the detected triple
Architecture : x86_64-apple-ios11.0.0
drops the -simulator environment. That may be the underlying problem.

I noticed the missing -simulator too, but I'm not sure where that comes from because the code is definitely compiled with -simulator.

I'll try to get a standalone repro case.

The missing -simulator definitely looks like a bug in LLDB, that's why I'm so interested in the testcase :-)

I have two ways of building, with Xcode and with Bazel. When building with Xcode, the log still shows the triple without -simulator. Also of note, it has the min OS as 11.0.0 which as far as I can tell, is never specified in our build, and not found in any of the build artifacts. All matches have 11.0 only. Could it be that the logged triple is constructed/synthesized and not a value coming from the binary?

That triple is definitely synthesized and somewhere in that path I'm suspecting the environment to get dropped. That's what I'd like to debug.

We have some precompiled third party libraries, and it turns out those were built with a triple that didn't have a -simulator environment. Could it be that lldb was seeing one of those? I'll rebuild those with -simulator and see if that changes anything with respect to the problem I described above.

  1. Create a simple iOS project (like Single View App) with Xcode 10 – to avoid UIScene and other iOS 13 APIS
  2. Set iOS Deployment Target to 11.0
  3. Open in either Xcode 10 or 11

In both cases, the types log shows the first call to SetTriple() with "x86_64-apple-ios11.0.0". Subsequent logs show the triple being set to the correct value with -simulator, from loaded .swiftmodules. Also, running script lldb.target.triple also shows the same incorrect triple, without -simulator.

Changing the deployment target to 13 corrects this problem. The log shows "x86_64-apple-ios13.0.0-simulator" and the value of lldb.target.triple is x86_64-apple-ios13.0.0-simulator.

We have some precompiled third party libraries, and it turns out those were built with a triple that didn't have a -simulator environment. Could it be that lldb was seeing one of those?

Yes but even if that is that case I would still consider that a bug in LLDB.

It may have been a red herring. The above repro instructions show the incorrect triple logging, using just a stock Xcode template.

@Adrian_Prantl I've filed a bug and a repro of the lldb issues we're hitting with lldb when disabling serialized debugging options: [SR-11485] Disabling -serialize-debugging-options breaks lldb Swift type loading · Issue #4481 · apple/llvm-project · GitHub

1 Like