Skip to content

IRGen: internalize symbols with -static #41431

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.

Sign up for GitHub

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

Jump to bottom
Merged
merged 1 commit into from
Feb 21, 2022
Merged

IRGen: internalize symbols with -static #41431

merged 1 commit into from
Feb 21, 2022

Conversation

compnerd
Copy link
Member

This pipes the -static flag when building a static library into IRGen.
This should have no impact on non-Windows targets as the usage of the
information simply removes the dllexport attribute on the generated
interfaces. This ensures that a library built with -static will not
re-export its interfaces from the consumer. This is important to ensure
that the consumer does not vend the API surface when it statically links
a library. In conjunction with the removal of the force load symbol,
this allows the generation of static libraries which may be linked
against on Windows. However, a subsequent change is needed to ensure
that the consumer does not mark the symbol as being imported from a
foreign module (i.e. dllimport).

Replace this paragraph with a description of your changes and rationale. Provide links to external references/discussions if appropriate.

Resolves SR-NNNN.

@compnerd
Copy link
Member Author

CC: @DougGregor @rjmccall @jckarter @aschwaighofer

As a brief recap of the model discussed on the forums a while ago:

  • -emit-library -shared (emit shared library)
    this is the current behaviour today

  • -emit-library -static (emit static library)
    makes all symbols local and will not mark for exporting (otherwise we would re-expose API from the consuming module, which could result in multiply defined symbols being exported from multiple modules and users linking arbitrarily to a version)

This could actually also enable optimizations on other platforms (-emit-library -static would allow all the symbols to be marked as __attribute__((__visibility__("hidden"))) on MachO and __attribute__((__visibility__("protected"))) on ELF). LLVM can then exploit the dso_local attribute to ensure that there are fewer PLT entries and that the symbols are relocated without the GOT/PLT. LTO could further internalize/change CC/inline/devirtualize as profitable.

At some point it may be nice to support

  • -emit-executable -static (prefer static linking)
  • -emit-executable -static -static-stdlib (fully static executable)
  • -emit-executable -shared (prefer dynamic linking)
  • -emit-executable -shared -static-stdlib (dynamically linked executable with static standard library)

@compnerd
Copy link
Member Author

@swift-ci please test

1 similar comment
@compnerd
Copy link
Member Author

@swift-ci please test

@compnerd
Copy link
Member Author

@swift-ci please test Linux platform

@compnerd compnerd force-pushed the externally-consumed-internally branch from 523e155 to d8de8fa Compare February 18, 2022 00:39
@compnerd
Copy link
Member Author

@swift-ci please test Linux platform

1 similar comment
@compnerd
Copy link
Member Author

@swift-ci please test Linux platform

@compnerd
IRGen: internalize symbols with -static
98bd2db 
This pipes the `-static` flag when building a static library into IRGen.
This should have no impact on non-Windows targets as the usage of the
information simply removes the `dllexport` attribute on the generated
interfaces.  This ensures that a library built with `-static` will not
re-export its interfaces from the consumer.  This is important to ensure
that the consumer does not vend the API surface when it statically links
a library.  In conjunction with the removal of the force load symbol,
this allows the generation of static libraries which may be linked
against on Windows.  However, a subsequent change is needed to ensure
that the consumer does not mark the symbol as being imported from a
foreign module (i.e. `dllimport`).
@compnerd compnerd force-pushed the externally-consumed-internally branch from 9a82a24 to 98bd2db Compare February 18, 2022 19:42
@compnerd
Copy link
Member Author

Please test with following PRs:
swiftlang/swift-corelibs-foundation#3144

@swift-ci please test

@compnerd
Copy link
Member Author

Please test with following PRs:
swiftlang/swift-corelibs-foundation#3144
#41204

@swift-ci please test Linux platform

@compnerd
Copy link
Member Author

Please test with following PRs:
swiftlang/swift-corelibs-foundation#3144
#41204

@swift-ci please test macOS platform

aschwaighofer
aschwaighofer approved these changes Feb 21, 2022
View reviewed changes
Copy link
Contributor

@aschwaighofer aschwaighofer left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

@compnerd compnerd merged commit d526dcf into swiftlang:main Feb 21, 2022
@compnerd compnerd deleted the externally-consumed-internally branch February 21, 2022 17:12
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Reviewers

@aschwaighofer aschwaighofer aschwaighofer approved these changes

Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging this pull request may close these issues.
2 participants
@compnerd @aschwaighofer