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

Add import_name_type parameter to #[link] #525

Closed
3 tasks done
dpaoliello opened this issue Jul 12, 2022 · 3 comments
Closed
3 tasks done

Add import_name_type parameter to #[link] #525

dpaoliello opened this issue Jul 12, 2022 · 3 comments
Labels
major-change A proposal to make a major change to rustc major-change-accepted A major change proposal that was accepted T-compiler Add this label so rfcbot knows to poll the compiler team

Comments

@dpaoliello
Copy link

dpaoliello commented Jul 12, 2022

Proposal

(This is another attempt at #495)

Add a new parameter, import_name_type, to the #[link] attribute to be used with #[link(kind = "raw-dylib")] when importing functions on i686-pc-windows-* targets.

Symbols that are exported or imported from a binary on i686 Windows can be named in four separate ways, corresponding to the import name types from the PE-COFF spec. The exporting and importing binaries must use the same name encoding, otherwise mismatches can lead to link failures due to "missing symbols" or to 0xc0000139 (STATUS_ENTRYPOINT_NOT_FOUND) errors when the executable/library is loaded. For details, see the comments on the raw-dylib feature's rust-lang/rust#58713. To generate the correct import libraries for these DLLs, therefore, rustc must know the import name type for each extern function, and there is currently no way for users to provide this information.

I propose adding a new MetaNameValueStr key to the #[link] attribute. This key would be called import_name_type, and it would accept one of three values: decorated, noprefix, and undecorated.

A single DLL is likely to export all its functions using the same import type name, hence import_name_type is a parameter of #[link] rather than being its own attribute that is applied per-function. It is possible to have a single DLL that exports different functions using different import name types, but users could express such cases by providing multiple export blocks for the same DLL, each with a different import name type.

Note: there is a fourth import name type defined in the PE-COFF spec, IMPORT_ORDINAL. This case is already handled by the #[link_ordinal] attribute. While it could be merged into import_type_name, that would not make sense as #[link_ordinal] provides per-function information (namely the ordinal itself).

Open points of discussion:

  • What does decorated mean for stdcall on GNU? dlltool doesn't include a leading _, should that be our behavior? Or should we add the _ to match MSVC? (I suggest: match MSVC - this gives us compatibility with the Win32 DLLs)
  • What is the desired behavior if import_name_type is not present on an extern block? Should the compiler signal an error, use the system default, or fully decorate? (I suggest: system default - this matches the behavior when not using raw-dylib)
  • Should the compiler signal an error or warning if import_name_type is provided in situations where it is not required, or should it silently ignore the extra parameter? These cases include the following:
    • Compiling for a target other than i686-pc-windows-* (I suggest: error - this has no effects except on i686-pc-windows-*, and matches the change to calling convention errors in Tracking issue for future-incompatibility lint unsupported_calling_conventions rust#87678).
    • Present in a #[link] attribute where kind is not "raw-dylib" (I suggest: error - this is a user error and will not do what they intended).
    • Present in a #[link] attribute on an extern block with a calling convention that doesn't decorate names (I suggest: error - this is a user error and will not do what they intended. NOTE: kind = "raw-dylib" already raises errors for unsupported calling conventions).

I have a prototype of this feature implemented via dpaoliello/rust@e86a32c

Mentors or Reviewers

Reviewer: @wesleywiser

Process

The main points of the Major Change Process are as follows:

  • File an issue describing the proposal.
  • A compiler team member or contributor who is knowledgeable in the area can second by writing @rustbot second.
    • Finding a "second" suffices for internal changes. If however, you are proposing a new public-facing feature, such as a -C flag, then full team check-off is required.
    • Compiler team members can initiate a check-off via @rfcbot fcp merge on either the MCP or the PR.
  • Once an MCP is seconded, the Final Comment Period begins. If no objections are raised after 10 days, the MCP is considered approved.

You can read more about Major Change Proposals on forge.

Comments

This issue is not meant to be used for technical discussion. There is a Zulip stream for that. Use this issue to leave procedural comments, such as volunteering to review, indicating that you second the proposal (or third, etc), or raising a concern that you would like to be addressed.

@dpaoliello dpaoliello added major-change A proposal to make a major change to rustc T-compiler Add this label so rfcbot knows to poll the compiler team labels Jul 12, 2022
@rustbot
Copy link
Collaborator

rustbot commented Jul 12, 2022

This issue is not meant to be used for technical discussion. There is a Zulip stream for that. Use this issue to leave procedural comments, such as volunteering to review, indicating that you second the proposal (or third, etc), or raising a concern that you would like to be addressed.

cc @rust-lang/compiler @rust-lang/compiler-contributors

@petrochenkov
Copy link

@rustbot second

@rustbot rustbot added the final-comment-period The FCP has started, most (if not all) team members are in agreement label Aug 1, 2022
@wesleywiser
Copy link
Member

@rustbot label -final-comment-period +major-change-accepted

@rustbot rustbot added major-change-accepted A major change proposal that was accepted to-announce Announce this issue on triage meeting and removed final-comment-period The FCP has started, most (if not all) team members are in agreement labels Aug 12, 2022
Dylan-DPC added a commit to Dylan-DPC/rust that referenced this issue Aug 25, 2022
…leywiser

Implementation of import_name_type

Fixes rust-lang#96534 by implementing rust-lang/compiler-team#525

Symbols that are exported or imported from a binary on 32bit x86 Windows can be named in four separate ways, corresponding to the [import name types](https://docs.microsoft.com/en-us/windows/win32/debug/pe-format#import-name-type) from the PE-COFF spec. The exporting and importing binaries must use the same name encoding, otherwise mismatches can lead to link failures due to "missing symbols" or to 0xc0000139 (`STATUS_ENTRYPOINT_NOT_FOUND`) errors when the executable/library is loaded. For details, see the comments on the raw-dylib feature's rust-lang#58713. To generate the correct import libraries for these DLLs, therefore, rustc must know the import name type for each `extern` function, and there is currently no way for users to provide this information.

This change adds a new `MetaNameValueStr` key to the `#[link]` attribute called `import_name_type`, and which accepts one of three values: `decorated`, `noprefix`, and `undecorated`.

A single DLL is likely to export all its functions using the same import type name, hence `import_name_type` is a parameter of `#[link]` rather than being its own attribute that is applied per-function. It is possible to have a single DLL that exports different functions using different import name types, but users could express such cases by providing multiple export blocks for the same DLL, each with a different import name type.

Note: there is a fourth import name type defined in the PE-COFF spec, `IMPORT_ORDINAL`. This case is already handled by the `#[link_ordinal]` attribute. While it could be merged into `import_type_name`, that would not make sense as `#[link_ordinal]` provides per-function information (namely the ordinal itself).

Design decisions (these match the MCP linked above):
* For GNU, `decorated` matches the PE Spec and MSVC rather than the default behavior of `dlltool` (i.e., there will be a leading `_` for `stdcall`).
* If `import_name_type` is not present, we will keep our current behavior of matching the environment (MSVC vs GNU) default for decorating.
* Using `import_name_type` on architectures other than 32bit x86 will result in an error.
* Using `import_name_type` with link kinds other than `"raw-dylib"` will result in an error.
@apiraino apiraino removed the to-announce Announce this issue on triage meeting label Aug 25, 2022
bors added a commit to rust-lang-ci/rust that referenced this issue Aug 27, 2022
…ywiser

Implementation of import_name_type

Fixes rust-lang#96534 by implementing rust-lang/compiler-team#525

Symbols that are exported or imported from a binary on 32bit x86 Windows can be named in four separate ways, corresponding to the [import name types](https://docs.microsoft.com/en-us/windows/win32/debug/pe-format#import-name-type) from the PE-COFF spec. The exporting and importing binaries must use the same name encoding, otherwise mismatches can lead to link failures due to "missing symbols" or to 0xc0000139 (`STATUS_ENTRYPOINT_NOT_FOUND`) errors when the executable/library is loaded. For details, see the comments on the raw-dylib feature's rust-lang#58713. To generate the correct import libraries for these DLLs, therefore, rustc must know the import name type for each `extern` function, and there is currently no way for users to provide this information.

This change adds a new `MetaNameValueStr` key to the `#[link]` attribute called `import_name_type`, and which accepts one of three values: `decorated`, `noprefix`, and `undecorated`.

A single DLL is likely to export all its functions using the same import type name, hence `import_name_type` is a parameter of `#[link]` rather than being its own attribute that is applied per-function. It is possible to have a single DLL that exports different functions using different import name types, but users could express such cases by providing multiple export blocks for the same DLL, each with a different import name type.

Note: there is a fourth import name type defined in the PE-COFF spec, `IMPORT_ORDINAL`. This case is already handled by the `#[link_ordinal]` attribute. While it could be merged into `import_type_name`, that would not make sense as `#[link_ordinal]` provides per-function information (namely the ordinal itself).

Design decisions (these match the MCP linked above):
* For GNU, `decorated` matches the PE Spec and MSVC rather than the default behavior of `dlltool` (i.e., there will be a leading `_` for `stdcall`).
* If `import_name_type` is not present, we will keep our current behavior of matching the environment (MSVC vs GNU) default for decorating.
* Using `import_name_type` on architectures other than 32bit x86 will result in an error.
* Using `import_name_type` with link kinds other than `"raw-dylib"` will result in an error.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
major-change A proposal to make a major change to rustc major-change-accepted A major change proposal that was accepted T-compiler Add this label so rfcbot knows to poll the compiler team
Projects
None yet
Development

No branches or pull requests

5 participants