Merge pull request #17665 from allevato/debug-prefix-map-wip

[allevato]

[Note: This is my first release branch cherry-pick PR, so I hope I've done this correctly. As with the response file PRs that were previously merged into 4.2, this would unblock and greatly improve the user experience for many of our Swift developers if it's not too late to get into this release. Thanks!]

• Explanation: Add the -debug-prefix-map flag to remap paths in debug info.

• Scope: This is the Swift implementation of the corresponding Clang -fdebug-prefix-map, which allows users to remap absolute paths in debug info to different (perhaps relative) paths that can be used verbatim or reverse-mapped by LLDB. This makes such builds reproducible and, more importantly, makes it possible for users to debug Swift binaries that have been built remotely on machines whose directory layout does not match that on their local machine.

• SR Issue: SR-5694

• Risk: I believe it to be low. There is a minor behavioral change w.r.t. debug info generation even when the flag is not in use (details) but I do not anticipate any regressions (see Testing below).

• Testing: The existing LLDB tests run during the PR cycle verify that the change did not cause regressions for existing debugging scenarios (i.e., where the -debug-prefix-map flag is not used). I have manually tested some scenarios debugging an executable built using the flag and am working on a follow-up PR to swift-lldb to add a test to cover this.

• Reviewers: @jrose-apple and @dcci (Implement -debug-prefix-map flag. #17665).

[jrose-apple]

@swift-ci Please test

[allevato]

Hi @tkremenek—referring to your forum post about post-convergence changes, could this change be a candidate for a potential 4.2.1 release? It would be a major boon to Google's ability to debug Swift binaries from distributed builds.

[tkremenek]

I sincerely apologize for now seeing this sooner, and I appreciate you filing the PR.

Swift 4.2.1 is a very focused release, and there are always a chance of regressions being introduced by changes like this. We should hold this fix to Swift 5.

I apologize for dropping the ball here; I need to find a better way to make sure these PRs as seen by the release manager in a timely manner. This change was probably proposed early enough for us to take, but it is too late now for 4.2.1. Totally my fault.