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-5694] Support -fdebug-compilation-dir #48264

Closed
swift-ci opened this issue Aug 15, 2017 · 9 comments
Closed

[SR-5694] Support -fdebug-compilation-dir #48264

swift-ci opened this issue Aug 15, 2017 · 9 comments
Assignees

Comments

@swift-ci
Copy link
Collaborator

swift-ci commented Aug 15, 2017

Previous ID SR-5694
Radar rdar://problem/88282133
Original Reporter dmishe (JIRA User)
Type New Feature
Status Resolved
Resolution Done
Additional Detail from JIRA
Votes 3
Component/s
Labels New Feature
Assignee @allevato
Priority Medium

md5: 389899ba40c7d8f4227678c675366a32

Issue Description:

There's a comment in Swift's frontend saying:

// TODO: Should we support -fdebug-compilation-dir?

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.

@swift-ci
Copy link
Collaborator Author

swift-ci commented Aug 15, 2017

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?

@swift-ci
Copy link
Collaborator Author

swift-ci commented Sep 11, 2017

Comment by Dmitry Shevchenko (JIRA)

Friendly ping @belkadan 🙂

@belkadan
Copy link
Contributor

belkadan commented Sep 11, 2017

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.

@swift-ci
Copy link
Collaborator Author

swift-ci commented Sep 11, 2017

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?

@swift-ci
Copy link
Collaborator Author

swift-ci commented Mar 21, 2018

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.

@allevato
Copy link
Collaborator

allevato commented Jul 25, 2018

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.

@adrian-prantl
Copy link
Member

adrian-prantl commented Jan 31, 2022

@swift-ci create

@keith
Copy link
Collaborator

keith commented Jan 31, 2022

Should we close now that #40735 is merged?

@adrian-prantl
Copy link
Member

adrian-prantl commented Feb 3, 2022

#40735

@swift-ci swift-ci transferred this issue from apple/swift-issues Apr 25, 2022
This issue was closed.
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

5 participants