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

Implement #[link_ordinal(n)] #89025

Merged
merged 1 commit into from
Oct 8, 2021
Merged

Conversation

ricobbe
Copy link
Contributor

@ricobbe ricobbe commented Sep 16, 2021

Allows the use of #[link_ordinal(n)] with #[link(kind = "raw-dylib")], allowing Rust to link against DLLs that export symbols by ordinal rather than by name. As long as the ordinal matches, the name of the function in Rust is not required to match the name of the corresponding function in the exporting DLL.

Part of #58713.

@rust-highfive
Copy link
Collaborator

r? @michaelwoerister

(rust-highfive has picked a reviewer for you, use r? to override)

@rust-highfive rust-highfive added the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Sep 16, 2021
@rust-log-analyzer

This comment has been minimized.

@rust-log-analyzer

This comment has been minimized.

compiler/rustc_metadata/src/native_libs.rs Outdated Show resolved Hide resolved
compiler/rustc_metadata/src/native_libs.rs Outdated Show resolved Hide resolved
compiler/rustc_metadata/src/native_libs.rs Outdated Show resolved Hide resolved
@ricobbe
Copy link
Contributor Author

ricobbe commented Sep 17, 2021

Question for reviewers: in attempting to clean up the error checking for link_ordinal in rustc_typeck/src/collect.rs beginning at about line 3156, I discovered that it's recording the ordinal, if present, to the function's CodegenFnAttrs struct. Should I be getting this information from there, rather than re-analyzing the attributes, in native_libs.rs? If so, how do I get a reference to the relevant CodegenFnAttrs object? Or should we drop this field from CodegenFnAttrs instead? As far as I can determine, it's only ever read by check_link_name_xor_ordinal in rustc_typeck/src/collect.rs.

(I refer to cleaning up the error checking because the messages rustc issues in certain circumstances are, at best, misleading: #[link_ordinal(3, 4)] is indeed invalid input, but complaining about an illegal argument format (unsuffixed integer value expected) in response is confusing.)

@est31
Copy link
Member

est31 commented Sep 18, 2021

@ricobbe I'm just giving my personal views here, am no reviewer in any official capacity, but I think that duplication should be avoided and ideally it should be re-used. I think it should be possible to obtain the attrs with something like self.tcx.codegen_fn_attrs(item.id.def_id), not entirely sure though.

Also, IMO the error message doesn't have to be perfect, but of course improvements are always nice.

@ricobbe
Copy link
Contributor Author

ricobbe commented Sep 20, 2021

@est31 Ok, I've pushed changes that use the info from CodegenFnAttrs. As another benefit, this also streamlines the error-detection code as well!

@rust-log-analyzer

This comment has been minimized.

@michaelwoerister
Copy link
Member

r? @joshtriplett

@ricobbe
Copy link
Contributor Author

ricobbe commented Sep 24, 2021

@joshtriplett do you have a sense of when you'll be able to take a look at this?

@joshtriplett
Copy link
Member

LGTM from a purely language perspective. Deferring to compiler folks on the implementation strategy.

@ricobbe
Copy link
Contributor Author

ricobbe commented Sep 24, 2021

LGTM from a purely language perspective. Deferring to compiler folks on the implementation strategy.

@joshtriplett Thanks for the review! I'm happy for the compiler folks to take a look at it, though I will say that this PR is a straightforward extension of the basic import-by-name raw-dylib work from PR #84171.

@joshtriplett
Copy link
Member

r? @michaelwoerister
for compiler team review of the implementation. No issues from a language semantics perspective.

@michaelwoerister
Copy link
Member

I'll take a look tomorrow.

@michaelwoerister
Copy link
Member

Looks great, @ricobbe! Thanks for adding so many tests.

@bors r+

@bors
Copy link
Contributor

bors commented Oct 7, 2021

@michaelwoerister: 🔑 Insufficient privileges: Not in reviewers

@michaelwoerister
Copy link
Member

@rust-lang/infra, any idea what that is about?

@michaelwoerister
Copy link
Member

Let's give it another try: @bors r+

@bors
Copy link
Contributor

bors commented Oct 7, 2021

📌 Commit 142f6c0 has been approved by michaelwoerister

@bors bors removed the S-waiting-on-review Status: Awaiting review from the assignee but also interested parties. label Oct 7, 2021
@bors bors added the S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion. label Oct 7, 2021
Manishearth added a commit to Manishearth/rust that referenced this pull request Oct 7, 2021
…ichaelwoerister

Implement `#[link_ordinal(n)]`

Allows the use of `#[link_ordinal(n)]` with `#[link(kind = "raw-dylib")]`, allowing Rust to link against DLLs that export symbols by ordinal rather than by name.  As long as the ordinal matches, the name of the function in Rust is not required to match the name of the corresponding function in the exporting DLL.

Part of rust-lang#58713.
Manishearth added a commit to Manishearth/rust that referenced this pull request Oct 8, 2021
…ichaelwoerister

Implement `#[link_ordinal(n)]`

Allows the use of `#[link_ordinal(n)]` with `#[link(kind = "raw-dylib")]`, allowing Rust to link against DLLs that export symbols by ordinal rather than by name.  As long as the ordinal matches, the name of the function in Rust is not required to match the name of the corresponding function in the exporting DLL.

Part of rust-lang#58713.
bors added a commit to rust-lang-ci/rust that referenced this pull request Oct 8, 2021
…ingjubilee

Rollup of 8 pull requests

Successful merges:

 - rust-lang#87918 (Enable AutoFDO.)
 - rust-lang#88137 (On macOS, make strip="symbols" not pass any options to strip)
 - rust-lang#88772 (Fixed confusing wording on Result::map_or_else.)
 - rust-lang#89025 (Implement `#[link_ordinal(n)]`)
 - rust-lang#89082 (Implement rust-lang#85440 (Random test ordering))
 - rust-lang#89288 (Wrapper for `-Z gcc-ld=lld` to invoke rust-lld with the correct flavor)
 - rust-lang#89476 (Correct decoding of foreign expansions during incr. comp.)
 - rust-lang#89622 (Use correct edition for panic in [debug_]assert!().)

Failed merges:

r? `@ghost`
`@rustbot` modify labels: rollup
@bors bors merged commit 6c17601 into rust-lang:master Oct 8, 2021
@rustbot rustbot added this to the 1.57.0 milestone Oct 8, 2021
@ricobbe ricobbe deleted the raw-dylib-link-ordinal branch October 13, 2021 21:36
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
S-waiting-on-bors Status: Waiting on bors to run and complete tests. Bors will change the label on completion.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

8 participants