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

Allow specification of the system V AMD64 ABI constraint. #34494

Merged
merged 9 commits into from
Sep 1, 2016

Conversation

CensoredUsername
Copy link
Contributor

This can be specified using extern "sysV64" fn on all platforms.

This ABI is used as the C ABI on unix platforms, but can only be specified there using extern "C". It was impossible to specify on other platforms. Meanwhile the win64 ABI, which was the extern "C" ABI on the windows platform could be specified on other platforms using extern "win64".

This pull request adds the the "sysV64" ABI constraint which exposes this calling convention on platforms where it is not the C ABI.

@rust-highfive
Copy link
Collaborator

Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @arielb1 (or someone else) soon.

If any changes to this PR are deemed necessary, please add them as extra commits. This ensures that the reviewer can see what has changed since they last reviewed the code. Due to the way GitHub handles out-of-date commits, this should also make it reasonably obvious what issues have or haven't been addressed. Large or tricky changes may require several passes of review and changes.

Please see the contribution instructions for more information.

@CensoredUsername
Copy link
Contributor Author

This solves #34388

@alexcrichton
Copy link
Member

cc @rust-lang/lang

This is unfortunately an "instantly stable" extension to the language, so we'll want to be sure to tread carefully here and ensure that it's named correctly/conventionally. (cc'ing to get some broader visibility)

@CensoredUsername
Copy link
Contributor Author

CensoredUsername commented Jun 27, 2016

I wasn't sure of the name myself either, so that's appreciated. As far as conventions go, gcc uses win_abi and sysv_abi and infers the correct calling convention from the target word size (cdecl for 32 bit on both, Microsoft x64/system V AMD64 for 64 bit). I went for sysV64 for similarity with win64, albeit a debate can be had on if the V should be capitalized or not (there was no clear pattern in capitalization in the rest of the calling conventions, so I chose to maintain the capitalization of the roman numeral).

@nrc
Copy link
Member

nrc commented Jun 27, 2016

bikeshed: would prefer sysv64 purely because the upper case V looks odd to me.

@CensoredUsername
Copy link
Contributor Author

I'll change it to sysv64 then, unless anyone objects.

@nikomatsakis
Copy link
Contributor

There is no reason that this has to be an insta-stable addition to the language, right? We have other ABIs (e.g., rust-call) that are feature-gated (though there were some bugfixes to that feature-gating recently).

@bors
Copy link
Contributor

bors commented Aug 3, 2016

☔ The latest upstream changes (presumably #35174) made this pull request unmergeable. Please resolve the merge conflicts.

@strega-nil
Copy link
Contributor

The reference also has a list of ABIs, and I'd request you also update that one.

@CensoredUsername
Copy link
Contributor Author

I'm aware, that list was added after this pull request was originally made.

@CensoredUsername
Copy link
Contributor Author

CensoredUsername commented Aug 27, 2016

Ok, it's been rebased to resolve the merge conflict and it has been feature gated behind feature(abi_sysv64). Additionally several tests have been added to:

  1. confirm the feature gate works,
  2. confirm that the right calling convention gets passed over to llvm,
  3. confirm that the right calling convention is used in the resulting binary.

One problem though is that it currently runs these tests for all platforms, instead the target architecture where it makes sense for (x86_64) because I'm not sure how to specify this for the tests.

@bors
Copy link
Contributor

bors commented Aug 30, 2016

☔ The latest upstream changes (presumably #36066) made this pull request unmergeable. Please resolve the merge conflicts.

This can be specified using `extern sysV64 fn` on all platforms
…tions and add the feature(abi_sysv64) to the list of known features
…d calling convention instead of just looking at the selected platform
… valid in non-codegen tests. Remove false positive in a test that relied on the exact formatting of an error string and rewrite the sysv64 register allocation test at it was triggering undefined behaviour
…dd another test that checks if the sysv64 abi corresponds to the same rules as the C abi on unix platforms
@CensoredUsername
Copy link
Contributor Author

Ok, the sysv64 ABI should now also pass the relevant tests that the C ABI passes on unix platforms. Additionally, a bug in the abi info computation should be fixed (where if you'd specify the "win64" calling convention on non-windows platforms it'd use the abi info code meant for the C (sysv64) abi).

@eddyb
Copy link
Member

eddyb commented Aug 31, 2016

@bors r=nagisa

@bors
Copy link
Contributor

bors commented Aug 31, 2016

📌 Commit 46a719e has been approved by nagisa


// Allows the sysV64 ABI to be specified on all platforms
// instead of just the platforms on which it is the C ABI
(active, abi_sysv64, "1.13.0", None)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@CensoredUsername you probably want to change None here to a tracking issue you should create before this gets landed, like the gates above.

@nagisa
Copy link
Member

nagisa commented Aug 31, 2016

r=me. The tests give enough confidence this is implemented properly, the ABI is feature-gated so there’s little concern about it becoming a maintenance burden and it fixes a bug wrt win64 too.

@eddyb
Copy link
Member

eddyb commented Aug 31, 2016

@bors r=nagisa

@bors
Copy link
Contributor

bors commented Aug 31, 2016

📌 Commit ad447a1 has been approved by nagisa

@bors
Copy link
Contributor

bors commented Sep 1, 2016

⌛ Testing commit ad447a1 with merge 2bd2272...

@bors
Copy link
Contributor

bors commented Sep 1, 2016

💔 Test failed - auto-win-gnu-64-opt

…o ignore windows entirely instead of just msvc
@CensoredUsername
Copy link
Contributor Author

I completely forgot that x86_64-windows-gnu is a thing and that it uses the win64 calling convention. Changed the ignore comment in the test from ignore-msvc to ignore-windows to fix it.

@eddyb
Copy link
Member

eddyb commented Sep 1, 2016

@bors r=nagisa

@bors
Copy link
Contributor

bors commented Sep 1, 2016

📌 Commit 3d766a0 has been approved by nagisa

@bors
Copy link
Contributor

bors commented Sep 1, 2016

⌛ Testing commit 3d766a0 with merge 933f471...

bors added a commit that referenced this pull request Sep 1, 2016
Allow specification of the system V AMD64 ABI constraint.

This can be specified using `extern "sysV64" fn` on all platforms.

This ABI is used as the C ABI on unix platforms, but can only be specified there using extern "C". It was impossible to specify on other platforms. Meanwhile the win64 ABI, which was the extern "C" ABI on the windows platform could be specified on other platforms using extern "win64".

This pull request adds the the "sysV64" ABI constraint which exposes this calling convention on platforms where it is not the C ABI.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

10 participants