Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[SR-7845] Compiler import search path behavior differs between debug/non-debug builds #50381

Open
allevato opened this issue Jun 1, 2018 · 2 comments

Comments

@allevato
Copy link
Collaborator

allevato commented Jun 1, 2018

Previous ID SR-7845
Radar None
Original Reporter @allevato
Type Bug

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
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.

@belkadan
Copy link
Contributor

belkadan commented Jun 4, 2018

There's a lot more going on here. I'll reply when I have time to write it up.

@allevato
Copy link
Collaborator Author

allevato commented Jun 4, 2018

Thanks, Jordan!

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:

changes in swift: master...allevato:fix-serialized-search-paths
changes in swift-lldb: apple/swift-lldb@stable...allevato:fix-serialized-search-paths

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.

@swift-ci swift-ci transferred this issue from apple/swift-issues Apr 25, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants