support debugging statically-linked Swift binaries on macOS

[tfiala]

This change supports the scenario of linking multiple Swift
module .o files with multiple .swiftmodule files provided to the
linker.

This change expects the "main" Swift module's .swiftmodule to be
specified first in the -add_ast_path directive given to the clang
linker line.

Fixes:
bugs.swift.org/SR-2637

[tfiala]

@swift-ci please test

[tfiala]

This still needs a test, but I'm running it through the CI to make sure it doesn't somehow break the Linux side.

[tfiala]

@swift-ci please test

[tfiala]

Hmm, swift-ci might be out to lunch. Checking in on that...

[tfiala]

@swift-ci please test

[tfiala]

The failure in the macOS build is happening at the Swift standard library level and is unrelated to this change:

/Users/buildnode/jenkins/workspace/swift-lldb-PR-osx/swift/stdlib/public/SDK/Foundation/URLRequest.swift /Users/buildnode/jenkins/workspace/swift-lldb-PR-osx/swift/stdlib/public/SDK/Foundation/UUID.swift /Users/buildnode/jenkins/workspace/swift-lldb-PR-osx/swift/stdlib/public/SDK/Foundation/Hashing.swift
/Users/buildnode/jenkins/workspace/swift-lldb-PR-osx/swift/stdlib/public/SDK/Foundation/Foundation.swift:978:19: error: subscript does not override any subscript from its superclass
  override public subscript(key: Any) -> Any? {
  ~~~~~~~~        ^
/Users/buildnode/jenkins/workspace/swift-lldb-PR-osx/swift/stdlib/public/SDK/Foundation/Foundation.swift:464:22: error: cannot convert value of type '[Any]' to expected argument type 'NSArray'
    self.init(array: elements)
                     ^~~~~~~~
                              as NSArray
/Users/buildnode/jenkins/workspace/swift-lldb-PR-osx/swift/stdlib/public/SDK/Foundation/Foundation.swift:560:25: error: 'map' produces '[T]', not the expected contextual result type 'OpaquePointer!'
      objects: elements.map { $0.1 as AnyObject },
                        ^
/Users/buildnode/jenkins/workspace/swift-lldb-PR-osx/swift/stdlib/public/SDK/Foundation/Foundation.swift:620:5: error: value of type 'NSDictionary' has no member 'enumerateKeysAndObjects'
    d.enumerateKeysAndObjects({
    ^ ~~~~~~~~~~~~~~~~~~~~~~~
/Users/buildnode/jenkins/workspace/swift-lldb-PR-osx/swift/stdlib/public/SDK/Foundation/Foundation.swift:668:6: error: value of type 'NSDictionary' has no member 'enumerateKeysAndObjects'
    d!.enumerateKeysAndObjects({
    ~^ ~~~~~~~~~~~~~~~~~~~~~~~
/Users/buildnode/jenkins/workspace/swift-lldb-PR-osx/swift/stdlib/public/SDK/Foundation/Foundation.swift:875:5: error: value of type 'NSSet' has no member 'enumerateObjects'
    s.enumerateObjects({
    ^ ~~~~~~~~~~~~~~~~
/Users/buildnode/jenkins/workspace/swift-lldb-PR-osx/swift/stdlib/public/SDK/Foundation/Foundation.swift:915:6: error: value of type 'NSSet' has no member 'enumerateObjects'
    s!.enumerateObjects({
    ~^ ~~~~~~~~~~~~~~~~

I'm going to do a local build and see if this has flushed out of stdlib master. If so, I'm going to rerun the macOS side of the build.

[tfiala]

I've got a note into the stdlib/foundation folks to look at that issue. I'm not seeing it replicated on normal CI. I'm going to go ahead and merge this. I'll pull it out if something unforeseen happens. I was mostly interested in making sure this didn't break the Linux side, since all the dev work for it is for the benefit of the macOS scenario.

[dmishe]

Todd, if I patch this change into the swift-3.0-RELEASE tag branch and build a toolchain from it, will it be functionally the same as the one shipping in Xcode 8 (sans shipping to the Store of course)?

[tfiala]

That should work, as long as the only thing you pull in is this patch.

Let me know how it goes!

-Todd

On Sep 17, 2016, at 12:22 PM, Dmitry Shevchenko notifications@github.com wrote:

Todd, if I patch this change into the swift-3.0-RELEASE tag branch and build a toolchain from it, will it be functionally the same as the one shipping in Xcode 8 (sans shipping to the Store of course)?

—
You are receiving this because you modified the open/close state.
Reply to this email directly, view it on GitHub, or mute the thread.