Tracking issue for "sysv64" calling convention

[CensoredUsername]

extern "sysv64" fn foo()

This solves #34388

An implementation is available in #34494

[jethrogb]

Can someone from lang team add relevant labels to this issue? cc @nikomatsakis since I think GitHub won't let me mention @rust-lang/lang directly.

[mikebenfield]

I am curious what is the status of this issue: is there any likelihood this will be stable in the near future?

Also, more broadly, what is the process these things go through and how can I monitor their progress? If I see a tracking issue like this with no comments in several months, is that an indication that it has stalled, or will the process still move forward?

[CensoredUsername]

As far as I know, to actually get this feature into stable rust an RFC needs to be written on its inclusion in rust. I have personally not had a reason to do so since I was forced to use nightly, but as this feature has existed for quite a while now for experimentation with no issues, writing an RFC on it might be a good idea.

(I think that nowadays the idea is that RFCs should always be written before a feature is added in-tree, but this was added before that was mandated)

[jethrogb]

I don't think an RFC is required for this one. The lang team just needs to sign off on it.

[nikomatsakis]

@CensoredUsername I'd be in favor of stabilizing, and happy to move to FCP, but I'd like the following data and I don't have time to gather it just now. Do you think you'd be able to do so? What would be useful is:

• A (short) write-up describing the ABI, placing it in the context of other systems, giving analogous features that are already stable
  • basically what you said on IRC, but in paragraph form =)
• A listing of what tests exist in the system that show it works properly
• A listing of known user(s) (if any)

This doesn't have to be long. Obviously this isn't a super complex feature. But it'd be great to have that documented and in one place, and it will help the lang team members gather up the required context.

[CensoredUsername]

This feature allows the System V AMD64 ABI to be explicitly specified as the calling convention for extern functions, using the extern "sysv64" syntax.

Description:

The System V AMD64 ABI is the default ABI for the AMD64 (also known as x64 or x86_64) processor architecture, it is used as the C ABI on all platforms except for Windows, which uses its own ABI that can be specified using extern "win64". This means that on non-windows operating systems, both the system V ABI as well as the Windows ABI can be specified. However, as it is currently impossible to explicitly specify the System V ABI, it is not possible to specify its use on windows, where the C ABI is the Windows ABI. This feature resolves this inconsistency by allowing the System V AMD64 abi to be explicitly specified as well.

There are several use cases that require being able to explicitly specify the used ABI independent of the used platform:

• Interfacing with assembly and naked functions: Calling rust functions from assembly (using the asm!() macro) or implementing naked functions rfc 1201 in a crossplatform way requires the ABI to be independent of the used platform.
• Interfacing with run-time generated code: Similarly, calling into run-time generated code from rust (and back again) requires a platform-independent ABI to be specified.
• Interfacing with foreign libraries explicitly specifying an ABI: In C compilers it is commonly possible to specify the exact ABI to use (on AMD64, gcc uses the ms_abi and sysv_abi specifiers). Interfacing with such C libraries in a crossplatform way requires Rust to be able to do this as well.
• Binary compatability libraries: To implement tools like WINE, being able to specify an ABI explicity is a requirement to interface with foreign code.

Tests:

To ensure that this feature works properly, tests have been added to confirm that the right ABI is passed to LLVM. Additionally on platforms where the extern "C" abi matches the System V abi the C ABI tests are repeated with the System V ABI specified. Finally, use of the correct calling convention on all AMD64 platforms is confirmed by calling a rust extern "sysv64" function from assembly.

Known uses:

avr-vm uses it to interface with run-time generated code in its AVR JIT: https://github.com/MackieLoeffel/avr-vm
https://github.com/make-a-demo-tool-in-rust/fish-in-a-jit

[nikomatsakis]

@rfcbot fcp merge

I propose to stabilize the sysv64 calling convention. @CensoredUsername did an excellent job writing up the situation here. I think my summary is that this is basically analogous to various other ABIs that we offer on stable Rust and which can be used in a cross-platform fashion.

I'm adding T-compiler on the FCP because I want to get the feedback of any T-compiler folk as to potential problems I am overlooking or other surprises.

Addendum:

Currently stable ABIs include:

            Abi::Cdecl |
            Abi::Stdcall |
            Abi::Fastcall |
            Abi::Aapcs |
            Abi::Win64 |
            Abi::Rust |
            Abi::C |
            Abi::System => {}

[rfcbot]

Team member @nikomatsakis has proposed to merge this. The next step is review by the rest of the tagged teams:

• @Aatch
• @arielb1
• @aturon
• @cramertj
• @eddyb
• @estebank
• @jseyfried
• @michaelwoerister
• @nikomatsakis
• @nrc
• @petrochenkov
• @pnkfelix
• @withoutboats

No concerns currently listed.

Once these reviewers reach consensus, this will enter its final comment period. If you spot a major issue that hasn't been raised at any point in this process, please speak up!

See this document for info about what commands tagged team members can give me.

[cramertj]

@rfcbot reviewed

[pnkfelix]

@rfcbot reviewed

[rfcbot]

🔔 This is now entering its final comment period, as per the review above. 🔔

[rfcbot]

🔔 This is now entering its final comment period, as per the review above. 🔔

[rfcbot]

The final comment period is now complete.