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-5694] Support -fdebug-compilation-dir #48264
Comments
Comment by Dmitry Shevchenko (JIRA) Not sure if supporting distributed builds, or having relocatable build outputs is something that is a goal for Swift right now. If it is, is there a bug tracking it? If it's not, why not? |
Comment by Dmitry Shevchenko (JIRA) Friendly ping @belkadan 🙂 |
It's a goal, but it's not a priority because there's so much else going on, and we haven't even fully scoped it. It's mostly not the build outputs that matter but everything else, particularly the search paths. I've talked about this some with @adrian-prantl, @ddunbar, and jingham@apple.com (JIRA User), but we've been focusing on other debugging improvements in the meantime. |
Comment by Dmitry Shevchenko (JIRA) Search paths matter for what, restoring the context during debugging? Sounds like any changes to the compiler will also need LLDB changes. What's the right approach to scoping this? I guess it's too early for a proposal. Maybe start an email thread to figure out everything that needs to be done? |
Comment by Nicholas Levin (JIRA) Unassigning from myself, since I haven't found the time for some number of weeks to really take this on. For the purposes of the macOS platform, normalizing the DWARF information in a dSYM bundle for Swift source code, the preferred flag to imitate would be -fdebug-prefix-map , rather than -fdebug-compilation-dir. Ideally it would be mapping all paths from a certain build root to a normalized token like ".", which could be remapped through lldb's settings target.source-map in an lldbinit file or a DBGSourcePathRemapping described in a UUID properly list embedded within each of the dSYM bundles. At least, that's how I think this problem should be handled. The Clang implementation of -fdebug-prefix-map handles this by replacing path substrings in the emitted debug information. I'm not yet aware of what else the Swift compiler frontend would need to do to handle this similarly. |
The implementation of -debug-prefix-map was merged in #17665 Remapping just the debug info paths, but not any search paths/ClangImporter options in swiftmodules, appears to be sufficient to make LLDB do the right thing for a standalone binary (one including .o files from one or multiple modules statically linked together along with all their ASTs via -add_ast_path, and even if those ASTs did not serialize debugging options). This is a reasonable first step; more complicated scenarios (involving, say, dynamic frameworks) may require more attention but we can explore those incrementally more easily with this initial implementation in place. |
@swift-ci create |
Should we close now that #40735 is merged? |
Additional Detail from JIRA
md5: 389899ba40c7d8f4227678c675366a32
Issue Description:
There's a comment in Swift's frontend saying:
I think the answer is a resounding "yes".
We saw this issue with distributed Swift builds, .swiftmodule outputs are really hard to cache because they write down absolute file paths on the builder machine.
The text was updated successfully, but these errors were encountered: