[SR-12933] lldb: Couldn't IRGen expression; with -no-serialize-debugging-options #4464
Version 11.5 (11E608c)
macOS 10.15.5 (19F96)
Swift trunk toolchain May 26, 2020
Additional Detail from JIRA
We get Couldn't IRGen expression, no additional error despite setting -no-serialize-debugging-options via SR-12783.
It seems that the header import paths are stored in the dSYM.
PSPDFKit 9.4pre, no-serialize, dSYMs available, master toolchain (May 26):
Full debugging flow:
Example to reproduce:
https://www.dropbox.com/s/pofzs6ly5syd86t/PSPDFKit-9.4pre-no-serialize.dmg?dl=1 (large file, can't upload here)
Note: It DOES WORK if you unpack in \tmp - seems like lldb can't find the dSYMs then? (Always delete derived data when moving)
it seems that this is fixed in master trunk:
I reported thus bug as FB7718242 on Feedback Assistant as well, but with much less understanding what's going on.
The text was updated successfully, but these errors were encountered:
Based on the description, you are running intro the issue discussed in https://bugs.swift.org/browse/SR-12783. The short answer is, if you are planning to ship a dSYM to another machine, you need to make sure to compiler with
I just double-checked the compiler sources and
It gets lowered to
and that option controls whether the Clang search paths are serialized in the .swiftmodule or not here:
Now evidently this isn't working as expected, so let's figure out why!
> Should it work like that? Is the dSYM bound to the machine it was built?
The goal for LLDB is to make this code path the default rather than a fallback, which will allow us to make
> I cannot find any binary size differences with -no-serialize-debugging-options; what does this change?
I'll investigate. You are supposed to see a difference in the binary .swiftmodule file, and by extension in the .dSYM (which contains a copy of all Swift modules).
> How does lldb find dSYM files? Same name+folder as the framework? Why does this fail in /tmp?
Thank you so much for filing this report! I was able to identify a bug in dsymutil that would misdirect LLDB to the .swiftmodule files on disk (the ones on the machine the .dSYM was built with), and disregard the ones included in the .dSYM itself. That could explain part of what we're seeing.
> Can I send you anything else to help?
Yes. I was unable to reproduce your report that
I can see that the Clang option block (for example
There is also a second thing I would curious about: In response to https://bugs.swift.org/browse/SR-12783, I changed LLDB to surface the underlying Clang errors instead of just saying
Comment by Franz Busch (JIRA)
@adrian-prantl I was just trying to debug this in our application as well since we are running into this problem constantly. We use Carthage and share the artefacts with ROME. That means one dev is building all the artefacts and then uploading them to an S3 bucket where everybody pulls them from. As far as I understood from the above we should be using -no-serialize-debugging-options to make this work.
What I tried now was to just build all deps locally again and then try to debug but I am still running into this IRGen issue. So I pulled the latest toolchain from June 4th and tried to debug again. Now I get a more expressive error but don't know how to properly interpret this:
warning: Swift error in fallback scratch context: error: module 'Swift' was created for incompatible target x86_64-apple-ios13.0-simulator: /Users/franzbusch/Library/Developer/Xcode/DerivedData/ModuleCache.noindex/Swift-2XSJ1TSBVFM44.swiftmodule note: This error message is displayed only once. If the error displayed above is due to conflicting search paths to Clang modules in different images of the debugged executable, this can slow down debugging of Swift code significantly, since a fresh Swift context has to be created every time a conflict is encountered. Can't construct shared Swift state for this process after repeated attempts. Giving up. Fatal errors: error: module 'Swift' was created for incompatible target x86_64-apple-ios13.0-simulator: /Users/franzbusch/Library/Developer/Xcode/DerivedData/ModuleCache.noindex/Swift-2XSJ1TSBVFM44.swiftmodule
One other interesting thing is that this is happening a lot if our static libs and their associated test bundle but in our main target we are able to po properly. However, we have to set a breakpoint in didFinishLaunching that does po application.
Peter, I'm sorry. I just realized that you had the answer to my second question already in your fantastic blog post:
That is very valuable information. This means that this is not failing because of Clang search path options, which explains, why
The error message itself points at something else going wrong:
I'll see if I can reproduce this.
One more thing I noticed in https://gist.github.com/steipete/515646a9840c91a61b73d1ab9f255bb3:
At the moment, you can not yet load a dSYM that contains a .swiftmodule produced by an older Swift compiler into an LLDB that was linked against a newer Swift compiler. LLDB may be able to find some of the types used in the public interface of PSPDFKit.framework in other dSYMs, and in the PSDPDFKit .swiftinterface but it will not be able to peek at the internals of the library, since most of the Swift types will be missing. That's just not supported (but being worked on).
Comment by Peter Steinberger (JIRA)
Adrian: Thanks so much for debugging this and for fixing the issue in dsymutil!
Apologies for the late reply. I've been running into a bunch of issues (https://twitter.com/steipete/status/1270756342295334914) trying to build our project with the Swift Trunk toolchain, but Slava Pestov [mentioned|https://twitter.com/slava_pestov/status/1271150466404155399] that a fix for Catalyst will land in a few days (most other issues I was able to work around or modify build settings)
Thanks also for explaining how lldb performs the dSYM lookup - this explains the behavior I've seen and I updated my blog post with it. In there I did a bin diff of the binaries and not the dSYM, which explains why I didn't find any differences in size with/without the flag - I looked at the wrong spot.
I'll wait for trunk to be fixed and then build a new version to test. Curiously we dropped iOS 11 with our upcoming 9.4 release and also enabled library evolution, and with the draft I can't reproduce the lldb issue anymore. Given how much trouble this made to reliably reproduce, I need to try this in a fresh VM again - will do both after our release next week.
Comment by keith siilats (JIRA)
I ran into this when trying to attach the Firebase binaries with carthage in Xcode 11.5 and 11.6. I think its only the performance one that does this. I tried the lldb log file but don't see anything obvious there. I also read your blog post but I dont see and Firebase related dsym files in the Carthage Build IOS folder, although there are some facebook ones that have older dates. Could anyone try to replicate with Cartfile containing:
Comment by Peter Steinberger (JIRA)
We're still working on getting everything built with Xcode 12b3; there's another lldb bug where it doesn’t work when the iOS deployment target is set to anything below iOS 13. FB8128033, also reported on https://developer.apple.com/forums/thread/651375.
There's also a crasher in Apple's security helper on the DTK that currently breaks our build script (FB8127506), but that's something we can work around.
I hope that by b4 FB8128033 is resolved and I can report back if this fix worked.
Unfortunately there is very little information in FB8128033 that would help diagnose what the root cause is. Based on the symptoms, it could be the bug that was fixed in #1548 (not yet in beta 3) but it's difficult to tell with neither a log nor a reproducer. [It is that bug if the types log under SwiftASTContextForExpressions::LogConfiguration shows an iOS target triple, where is should be using an ios-simulator target triple]. I understand that sharing a reproducer can be difficult. Perhaps you can try with a downloadable 5.3 toolchain https://swift.org/download/#snapshots from Jul 27+? Otherwise I need more information to work with.
Currently, without these Swift flags, importing LibWally as a framework breaks LLDB. More information can be found in these LLVM issues: apple/llvm-project#4467 apple/llvm-project#4464 And a great summary can be found here: https://steipete.com/posts/couldnt-irgen-expression