Tracking issue for RFC 2627: #[link(kind="raw-dylib")]

[joshtriplett]

This is the tracking issue for RFC 2627, #[link(kind="raw-dylib")].

Note: raw-dylib and link_ordinal are now stabilized in 1.65 on Windows for x86_64, aarch64, and thumbv7a (not 32-bit x86) via #99916.

Opens:

• Implementation for Windows (top priority) (msvc: Partial support for raw-dylib linkage #84171) (gnu: Implement raw-dylib support for windows-gnu #90782)
  • Emitting idata sections
  • New link_ordinal attribute (Implement #[link_ordinal(n)] #89025)
  • Testing in winapi/windows-rs with nightly Rust before stabilization (Enables experimental support for raw-dylib microsoft/windows-rs#977 and Switch Direct2D sample to use raw-dylib microsoft/windows-samples-rs#18)
  • Supporting all calling conventions
    • cdecl
    • stdcall
    • fastcall
    • vectorcall
• Tests, including all the corner cases mentioned in the reference-level explanation
• Documentation (Add docs for raw-dylib to unstable book #87315)
• Implementation for Linux (Tracking Issue for raw-dylib on ELF #135694)
  • Stabilized?
• Implementation for macOS (Tracking Issue for raw_dylib_macho #146356)
  • Stabilized?
• Implementation for other platforms
• Implementation of a pure Rust target for Windows (no libc, no msvc, no mingw). This may require another RFC

[crlf0710]

cc rust-lang/rfcs#1061

[ZerothLaw]

I don't think I have the expertise to implement this feature, but I could write some (currently failing) tests for use by the implementor?

(Background, Ran into this exact problem linking mscorlib.dll into executables. Had to write a C++ level wrapper to get it to work.)

[crlf0710]

A very first PR has landed, now the link_ordinal attribute is added. Want to say thank you to @Centril for helping me on this~

[retep998]

There's now a bounty for this issue to incentivize someone to work on implementing this feature.

https://www.bountysource.com/issues/70533351-tracking-issue-for-rfc-2627-link-kind-raw-dylib

[est31]

Some information I've gathered:

• The spec can be found here. It's a bit hard to understand in isolation as it's incomplete and some numbers are given in bits and others in bytes. You need to figure this out from other resources (see below).
• We ONLY have to worry about the .idata section. Despite the syntax suggesting the opposite, the information is purely additive and doesn't change ANYTHING about the import itself (additional attribute in LLVM IR, etc). Roughly, .lib files that this feature wants to make unneccessary are condensed idata sections and the linker extracts the relevant ones for us. This is good for us because we don't need LLVM to support any custom attributes. Not tried it, but emitting additional sections should be enough, and there is LLVM API support for adding sections.
• We'll have to generate not a single .idata section but rather multiple .idata$2, .idata$3, .idata$4, .idata$6, .idata$7 ones. See this part of the spec that explains the rationale
• @SlugFiller has given a nice example in the original issue Produce idata content for dll/dylib import on windows #30027 in terms of llvm IR code what has to be done.
• Basically, one "only" needs to create this IR code via the llvm API wrappers. The place for this is the librustc_codegen_llvm crate. One probably has to invoke the llvm::LLVMSetSection function in some fashion (just giving you something to grep for)
• The current size check as of Add feature gate for raw_dylib. #63948 for the ordinals is too tolerant. The spec (section "import lookup table") only allocates 16 bits for both PE32 and PE32+.

To my best knowledge, these are the meanings of the .idata$* sections. See the spec/example for further understanding:

section	name in the MS spec	description
.idata$2	Import directory table	main list containing pointers into the other tables. Each entry in the list concerns one dll and contains pointers to the import address/lookup table, dll name table
.idata$3	Import Address Table	At compile time same as import lookup table. Just duplicate the output! Not sure whether it's actually .idata$5
.idata$4	Import Lookup Table	Has pointers to the function names
.idata$6	Hint/Name Table	Contains the names of the functions we want to import. Also contains export name table hints which are NOT the same as ordinals and we'll probably have to set to 0
.idata$7	No name in the MS spec, let's call it DLL name table	Contains the names for the dll files

The main table is the import directory table which contains pointers into the other tables. Linkers are smart enough to assemble all the relative pointers.

As for who's implementing it, I've stopped contributing patches to the compiler years ago. Better someone else does it. Hope that with my help instructions and @retep998 's bounty there will be some movement on this. Of course I'm around to answer questions.