diff options
| author | bors <bors@rust-lang.org> | 2022-08-27 03:19:12 +0000 |
|---|---|---|
| committer | bors <bors@rust-lang.org> | 2022-08-27 03:19:12 +0000 |
| commit | 9845f4c47e7062867c73b6bed8f1df273b56d5d7 (patch) | |
| tree | 96c457490b4ae27638a3be40daa381fedf948f2a /compiler/rustc_session/src | |
| parent | bb8a08f011ce481adc62e45150b642d1f160bd78 (diff) | |
| parent | cc49c3e582ae2c597954fe877774d8bc32427dc3 (diff) | |
| download | rust-9845f4c47e7062867c73b6bed8f1df273b56d5d7.tar.gz rust-9845f4c47e7062867c73b6bed8f1df273b56d5d7.zip | |
Auto merge of #100732 - dpaoliello:import_name_type, r=wesleywiser
Implementation of import_name_type Fixes #96534 by implementing https://github.com/rust-lang/compiler-team/issues/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 https://github.com/rust-lang/rust/issues/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.
Diffstat (limited to 'compiler/rustc_session/src')
| -rw-r--r-- | compiler/rustc_session/src/cstore.rs | 33 |
1 files changed, 32 insertions, 1 deletions
diff --git a/compiler/rustc_session/src/cstore.rs b/compiler/rustc_session/src/cstore.rs index c1fd3c7c61b..11ef75bb2d4 100644 --- a/compiler/rustc_session/src/cstore.rs +++ b/compiler/rustc_session/src/cstore.rs @@ -81,10 +81,29 @@ impl NativeLib { } } +/// Different ways that the PE Format can decorate a symbol name. +/// From <https://docs.microsoft.com/en-us/windows/win32/debug/pe-format#import-name-type> +#[derive(Copy, Clone, Debug, Encodable, Decodable, HashStable_Generic, PartialEq, Eq)] +pub enum PeImportNameType { + /// IMPORT_ORDINAL + /// Uses the ordinal (i.e., a number) rather than the name. + Ordinal(u16), + /// Same as IMPORT_NAME + /// Name is decorated with all prefixes and suffixes. + Decorated, + /// Same as IMPORT_NAME_NOPREFIX + /// Prefix (e.g., the leading `_` or `@`) is skipped, but suffix is kept. + NoPrefix, + /// Same as IMPORT_NAME_UNDECORATE + /// Prefix (e.g., the leading `_` or `@`) and suffix (the first `@` and all + /// trailing characters) are skipped. + Undecorated, +} + #[derive(Clone, Debug, Encodable, Decodable, HashStable_Generic)] pub struct DllImport { pub name: Symbol, - pub ordinal: Option<u16>, + pub import_name_type: Option<PeImportNameType>, /// Calling convention for the function. /// /// On x86_64, this is always `DllCallingConvention::C`; on i686, it can be any @@ -92,6 +111,18 @@ pub struct DllImport { pub calling_convention: DllCallingConvention, /// Span of import's "extern" declaration; used for diagnostics. pub span: Span, + /// Is this for a function (rather than a static variable). + pub is_fn: bool, +} + +impl DllImport { + pub fn ordinal(&self) -> Option<u16> { + if let Some(PeImportNameType::Ordinal(ordinal)) = self.import_name_type { + Some(ordinal) + } else { + None + } + } } /// Calling convention for a function defined in an external library. |
