You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Swift version 4.2-dev (LLVM 3c04b0ea85, Clang 197a5d4e3b, Swift db75a67)
Target: x86_64-unknown-linux-gnu
Additional Detail from JIRA
Votes
1
Component/s
Compiler
Labels
Bug
Assignee
None
Priority
Medium
md5: 48c28e46eb0b49002f208ae84787af69
Issue Description:
When the -Xfrontend -serialize-debugging-options flag is passed to the compiler, it causes import search paths, framework search paths, and ClangImporter options to be written into the .swiftmodule files, so that LLDB can read them for debugging purposes.
However, these values, if present, are also unconditionally loaded by the compiler during normal compilation actions, and thus they have effects there as well (see ModuleFile.cpp).
Thus, it is possible to construct swiftc invocations that succeed or fail depending solely on whether debug options are serialized or not.
All the code that serializes these paths and ClangImporter options seems to indicate that they are intended to be used for debugging only, so I believe that one way to fix this would be to add a flag of some sort to ASTContext that indicates whether debug options should be loaded; lldb would set it and the compiler would omit it.
As far as I can tell, fixing this should be a safe, non-breaking change; it would only have the potential to break people who never build with debugging turned off and who don't pass correct import search paths to the compiler in all cases. However, if I comment out the lines in ModuleFile.cpp that I linked to above, I see that 5 of the compiler's tests fail. I'm digging into it more, but I believe these tests are making incorrect assumptions about the search paths and that fixing them is the correct course of action.
STEPS TO REPRODUCE
1. Download the attached zip file.
2. Run ./build.sh and observe that the build fails with the error "missing required module 'ModuleA'"
3. Run ./build.sh -Xfrontend -serialize-debugging-options and observe that the build succeeds.
4. Add -I nested to the compile options for compiling ModuleC.swift and run ./build.sh without additional arguments; observe that the build succeeds.
The text was updated successfully, but these errors were encountered:
In the meantime, I've been tinkering with a change here that adds a boolean to SerializedModuleLoader so that LLDB can still load the search paths but the compiler wouldn't:
I haven't opened the PR yet because I imagine most of you are quite busy this week 🙂 I'm looking forward to your insight—my fear is that someone might be relying on this behavior for non-debug builds (which is why I'm surprised that the behavior of -serialize-debugging-options isn't just tied to the presence of a -g group flag), or that there are other unintended consequences.
Attachment: Download
Environment
Tested on a recent Swift dev snapshot on Linux.
Swift version 4.2-dev (LLVM 3c04b0ea85, Clang 197a5d4e3b, Swift db75a67)
Target: x86_64-unknown-linux-gnu
Additional Detail from JIRA
md5: 48c28e46eb0b49002f208ae84787af69
Issue Description:
When the
-Xfrontend -serialize-debugging-options
flag is passed to the compiler, it causes import search paths, framework search paths, and ClangImporter options to be written into the .swiftmodule files, so that LLDB can read them for debugging purposes.However, these values, if present, are also unconditionally loaded by the compiler during normal compilation actions, and thus they have effects there as well (see ModuleFile.cpp).
Thus, it is possible to construct
swiftc
invocations that succeed or fail depending solely on whether debug options are serialized or not.All the code that serializes these paths and ClangImporter options seems to indicate that they are intended to be used for debugging only, so I believe that one way to fix this would be to add a flag of some sort to
ASTContext
that indicates whether debug options should be loaded; lldb would set it and the compiler would omit it.As far as I can tell, fixing this should be a safe, non-breaking change; it would only have the potential to break people who never build with debugging turned off and who don't pass correct import search paths to the compiler in all cases. However, if I comment out the lines in ModuleFile.cpp that I linked to above, I see that 5 of the compiler's tests fail. I'm digging into it more, but I believe these tests are making incorrect assumptions about the search paths and that fixing them is the correct course of action.
STEPS TO REPRODUCE
1. Download the attached zip file.
2. Run
./build.sh
and observe that the build fails with the error "missing required module 'ModuleA'"3. Run
./build.sh -Xfrontend -serialize-debugging-options
and observe that the build succeeds.4. Add
-I nested
to the compile options for compilingModuleC.swift
and run./build.sh
without additional arguments; observe that the build succeeds.The text was updated successfully, but these errors were encountered: